idnits 2.17.1 draft-ietf-6lowpan-nd-10.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4944, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- 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 (June 17, 2010) is 5052 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SLLAO' is mentioned on line 1684, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-autoconf-adhoc-addr-model (ref. 'I-D.ietf-autoconf-adhoc-addr-model') ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-15) exists of draft-ietf-6lowpan-hc-07 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lowpan Working Group Z. Shelby, Ed. 3 Internet-Draft Sensinode 4 Updates: 4944 (if approved) S. Chakrabarti 5 Intended status: Standards Track IP Infusion 6 Expires: December 19, 2010 E. Nordmark 7 Oracle, Inc. 8 June 17, 2010 10 Neighbor Discovery Optimization for Low-power and Lossy Networks 11 draft-ietf-6lowpan-nd-10 13 Abstract 15 The IETF 6LoWPAN working group defines IPv6 for low-power and lossy 16 networks (LLNs) such as IEEE 802.15.4. This and other similar link 17 technologies have limited or no usage of multicast signaling due to 18 energy conservation. In addition, the wireless network may not 19 strictly follow traditional concept of IP subnets and IP links. IPv6 20 Neighbor Discovery was not designed for non-transitive wireless 21 links. The traditional IPv6 link concept and heavy use of multicast 22 make the protocol inefficient and sometimes impractical in a low 23 power and lossy network. This document describes simple 24 optimizations to IPv6 Neighbor Discovery, addressing mechanisms and 25 duplicate address detection for 6LoWPAN and similar networks. 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 December 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. The Shortcomings of IPv6 Neighbor Discovery . . . . . . . 5 69 1.2. Mesh-under and Route-over Concepts . . . . . . . . . . . . 6 70 1.3. Applicability, Goals and Assumptions . . . . . . . . . . . 7 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1. Extensions to RFC4861 . . . . . . . . . . . . . . . . . . 10 74 3.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 75 3.3. Host-to-Router Interaction . . . . . . . . . . . . . . . . 12 76 3.4. Router-to-Router Interaction . . . . . . . . . . . . . . . 13 77 4. New Neighbor Discovery Options . . . . . . . . . . . . . . . . 13 78 4.1. Address Registration Option . . . . . . . . . . . . . . . 13 79 4.2. 6LoWPAN Context Option . . . . . . . . . . . . . . . . . . 16 80 4.3. Authoritative Border Router Option . . . . . . . . . . . . 17 81 5. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 18 82 5.1. Forbidden Actions . . . . . . . . . . . . . . . . . . . . 19 83 5.2. Interface Initialization . . . . . . . . . . . . . . . . . 19 84 5.3. Sending a Router Solicitation . . . . . . . . . . . . . . 19 85 5.4. Processing a Router Advertisement . . . . . . . . . . . . 20 86 5.4.1. Address configuration . . . . . . . . . . . . . . . . 20 87 5.4.2. Storing Contexts . . . . . . . . . . . . . . . . . . . 20 88 5.4.3. Maintaining Prefix and Context Information . . . . . . 21 89 5.5. Registration and Neighbor Unreachability Detection . . . . 21 90 5.5.1. Sending a Neighbor Solicitation . . . . . . . . . . . 22 91 5.5.2. Processing a Neighbor Advertisement . . . . . . . . . 22 92 5.5.3. Recovering from Failures . . . . . . . . . . . . . . . 22 93 5.6. Next-hop Determination . . . . . . . . . . . . . . . . . . 23 94 5.7. Address Resolution . . . . . . . . . . . . . . . . . . . . 23 95 5.8. Sleeping . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 5.8.1. Picking an Appropriate Registration Lifetime . . . . . 24 97 5.8.2. Behavior on Wakeup . . . . . . . . . . . . . . . . . . 24 98 6. Router Behavior for 6LR and 6LBR . . . . . . . . . . . . . . . 24 99 6.1. Forbidden Actions . . . . . . . . . . . . . . . . . . . . 25 100 6.2. Interface Initialization . . . . . . . . . . . . . . . . . 25 101 6.3. Processing a Router Solicitation . . . . . . . . . . . . . 25 102 6.4. Periodic Router Advertisements . . . . . . . . . . . . . . 26 103 6.5. Processing a Neighbor Solicitation . . . . . . . . . . . . 26 104 6.5.1. Checking for Duplicates . . . . . . . . . . . . . . . 26 105 6.5.2. Updating the Neighbor Cache . . . . . . . . . . . . . 27 106 6.5.3. Address Resolution between Routers . . . . . . . . . . 27 107 6.5.4. Neighbor Unreachability Detection . . . . . . . . . . 27 108 7. Border Router Behavior . . . . . . . . . . . . . . . . . . . . 28 109 7.1. Prefix Determination . . . . . . . . . . . . . . . . . . . 28 110 7.2. Context Configuration and Management . . . . . . . . . . . 28 111 8. Optional Behavior . . . . . . . . . . . . . . . . . . . . . . 29 112 8.1. Multihop Prefix and Context Distribution . . . . . . . . . 29 113 8.1.1. 6LBRs Sending Router Advertisements . . . . . . . . . 30 114 8.1.2. Routers Sending Router Solicitations . . . . . . . . . 30 115 8.1.3. Routers Processing Router Advertisements . . . . . . . 30 116 8.1.4. Storing the Information . . . . . . . . . . . . . . . 31 117 8.1.5. Sending Router Advertisements . . . . . . . . . . . . 31 118 8.2. Duplicate Address Detection . . . . . . . . . . . . . . . 32 119 8.2.1. Special Message Validation . . . . . . . . . . . . . . 33 120 8.2.2. Conceptual Data Structures . . . . . . . . . . . . . . 33 121 8.2.3. 6LR Sending a special Neighbor Solicitation . . . . . 34 122 8.2.4. 6LBR Receiving a special Neighbor Solicitation . . . . 34 123 8.2.5. Processing a special Neighbor Advertisement . . . . . 35 124 8.2.6. Recovering from Failures . . . . . . . . . . . . . . . 35 125 9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 35 126 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 127 10.1. Message Examples . . . . . . . . . . . . . . . . . . . . . 36 128 10.2. Bootstrapping Example . . . . . . . . . . . . . . . . . . 37 129 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 130 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 131 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 132 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 40 133 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 134 15.1. Normative References . . . . . . . . . . . . . . . . . . . 44 135 15.2. Informative References . . . . . . . . . . . . . . . . . . 45 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 138 1. Introduction 140 The IPv6-over-IEEE 802.15.4 [RFC4944] document specifies how IPv6 is 141 carried over an IEEE 802.15.4 network with the help of an adaptation 142 layer which sits between the MAC layer and the IP network layer. A 143 link in a LoWPAN is characterized as lossy, low-power, low bit-rate, 144 short range, with many nodes saving energy with long sleep periods. 145 Multicast as used in IPv6 Neighbor Discovery [RFC4861] is not 146 desirable in such a wireless low-power and lossy network. Moreover, 147 LoWPAN links are asymmetric and non-transitive in nature. A LoWPAN 148 is potentially composed of a large number of overlapping radio 149 ranges. Although a given radio range has broadcast capabilities, the 150 aggregation of these is a complex Non-Broadcast MultiAccess (NBMA, 151 [RFC2491]) structure with generally no LoWPAN-wide multicast 152 capabilities. Link-local scope is in reality defined by reachability 153 and radio strength. Thus we can consider a LoWPAN to be made up of 154 links with undetermined connectivity properties as in 155 [I-D.ietf-autoconf-adhoc-addr-model], along with the corresponding 156 address model assumptions defined therein. 158 This specification introduces the following optimizations to IPv6 159 Neighbor Discovery [RFC4861] specifically aimed at low-power and 160 lossy networks such as LoWPANs: 162 o Host-initiated interactions to allow for sleeping hosts. 164 o Elimination of multicast-based address resolution. 166 o Elimination of redirects since they are problematic on links with 167 non-transitive connectivity. 169 o A host address registration feature using a new option in unicast 170 Neighbor Solicitation and Neighbor Advertisement messages. 172 o A new Neighbor Discovery option to distribute 6LoWPAN header 173 compression context to hosts. 175 o Optional multihop distribution of prefix and 6LoWPAN header 176 compression context. 178 o Optional multihop duplicate address detection. 180 The document defines three new ICMPv6 message options: the required 181 Address Registration option and the optional Authoritative Border 182 Router and 6LoWPAN Context options. 184 1.1. The Shortcomings of IPv6 Neighbor Discovery 186 IPv6 Neighbor Discovery [RFC4861] provides several important 187 mechanisms used for Router Discovery, Address Resolution, Duplicate 188 Address Detection, Redirect, along with Prefix and Parameter 189 Discovery. 191 Following power-on and initialization of the network in IPv6 Ethernet 192 networks, a node joins the solicited-node multicast address on the 193 interface and then performs Duplicate Address Detection (DAD) for the 194 acquired link-local address by sending a solicited-node multicast 195 message to the link. After that it sends multicast messages to the 196 all-router address to solicit router advertisements. If the host 197 receives a valid Router Advertisement with the "A" flag, it 198 autoconfigures the IPv6 address with the advertised prefix in the 199 Router Advertisement (RA) message. Besides this, the IPv6 routers 200 usually send router advertisements periodically on the network. RAs 201 are sent to the all-node multicast address. Nodes send Neighbor 202 Solicitation/Neighbor Advertisement messages to resolve the IPv6 203 address of the destination on the link. The Neighbor Solicitation 204 messages used for address resolution are multicast. The Duplicate 205 Address Detection procedure and the use of periodic Router 206 Advertisement messages assumes that the nodes are powered on and 207 reachable most of the time. 209 In Neighbor Discovery the routers find the hosts by assuming that a 210 subnet prefix maps to one broadcast domain, and then multicast 211 Neighbor Solicitation messages to find the host and its link-layer 212 address. Furthermore, the DAD of use multicast assumes that all 213 hosts that autoconfigure IPv6 addresses from the same prefix can be 214 used using link-local multicast messages. 216 Note that the 'L' (on-link) bit in the Prefix Information option can 217 be set to zero in Neighbor Discovery, which makes the host not use 218 multicast Neighbor Solicitation (NS) messages for address resolution 219 of other hosts, but routers still use multicast NS messages to find 220 the hosts. 222 In a LoWPAN, primarily two types of network topologies are found - 223 star networks and mesh networks. A star network is similar to a 224 regular IPv6 subnet with a router and a set of nodes connected to it 225 via the same non-transitive link. But in Mesh networks, the nodes 226 are capable of routing and forwarding packets. Due to the lossy 227 nature of wireless communication and a changing radio environment, 228 the IPv6-link node-set may change due to external physical factors. 229 Thus the link is often unstable and the nodes appear to be moving 230 without moving physically. 232 A LoWPAN can use two types of link-layer addresses; 16-bit short 233 addresses and 64-bit unique addresses as defined in [RFC4944]. 234 Moreover, the available link-layer payload size is on the order of 235 less than 100 bytes thus header compression is very useful. 237 Considering the above characteristics in a LoWPAN, and the IPv6 238 Neighbor Discovery [RFC4861] protocol design center, some 239 optimizations and extensions to Neighbor Discovery are useful for the 240 wide deployment of IPv6 over low-powered and lossy networks such as 241 6LoWPANs. 243 1.2. Mesh-under and Route-over Concepts 245 In the 6LoWPAN context, often a link-layer mesh routing mechanism is 246 referred to as "mesh-under" while routing/forwarding packets using 247 IP-layer addresses is referred to as "route-over". The difference 248 between mesh-under and route-over is similar to a bridged-network 249 versus IP-routing using Ethernet. In a mesh-under network all nodes 250 are on the same link which is served by one or more routers, which we 251 call 6LoWPAN Border Routers (6LBR). In a route-over network, there 252 are multiple links in the 6LoWPAN. Unlike fixed IP links, these 253 link's members may be changing due to the nature of the low-power and 254 lossy behavior of wireless technology. Thus a route-over network is 255 made up of a flexible set of links interconnected by interior 256 routers, which we call 6LoWPAN Routers (6LR). 258 This specification is applicable to both mesh-under and route-over 259 networks. However, in route-over networks, we have two types of 260 routers - 6LBRs and 6LRs. 6LoWPAN Border Routers sit at the boundary 261 of the 6LoWPAN and the rest of the network while 6LoWPAN Routers are 262 inside the LoWPAN. 6LoWPAN Routers are assumed to be running a 263 routing protocol. 265 In a mesh-under configuration a 6LBR is acting as the IPv6 router 266 where all the hosts in the LoWPAN are on the same link, thus they are 267 only one IP hop away. No 6LoWPAN Routers exist in this topology as 268 forwarding is handled by a link-layer mesh routing protocol. 270 In a route-over configuration, Neighbor Discovery operations take 271 place between hosts and 6LRs or 6LBRs. The 6LR nodes are able to 272 send and receive Router Advertisements, Router Solicitations as well 273 as forward and route IPv6 packets. Here packet forwarding happens at 274 the routing layer. 276 In both types of configurations, hosts do not take part in routing 277 and forwarding packets and they act as simple IPv6 hosts. 279 1.3. Applicability, Goals and Assumptions 281 The optimizations described in this document are most useful for 282 route-over and mesh-under configurations in Mesh topologies. 283 However, Star topology configurations will also benefit from the 284 optimizations due to minimized signaling, robust handling of the non- 285 transitive link, and header compression context information. 287 The document has the following main goals and assumptions 289 Goals: 291 o Optimize Neighbor Discovery with a mechanism that is minimal yet 292 sufficient for the operation in both mesh-under and route-over 293 configurations. 295 o Make the host to router interaction the same whether mesh-under or 296 route-over is used. 298 o Minimize signaling by avoiding the use of multicast flooding and 299 reducing the use of link-scope multicast messages. 301 o Optimize the interfaces between hosts and their default routers. 303 o Support for sleeping hosts. 305 o Minimize the complexity of nodes. 307 o Disseminate context information to hosts as needed by 308 [I-D.ietf-6lowpan-hc]. 310 o Optionally disseminate context information and prefix information 311 from the border to all routers in a LoWPAN. 313 o Optional duplicate address detection mechanism suitable for route- 314 over LoWPANs. 316 Assumptions: 318 o EUI-64s are globally unique. 320 o All nodes in the LLN have an EUI-64 interface identifier in order 321 to do address auto-configuration and detect duplicate addresses. 323 o The link layer technology is assumed to be low-power and lossy, 324 exhibiting undetermined connectivity, such as IEEE 802.15.4 325 [RFC4944]. However, the Address Registration mechanism might be 326 useful for other link layer technologies. 328 o A 6LoWPAN is configured with one or more global IPv6 address 329 prefixes to enable hosts to move between routers in the 6LoWPAN 330 without changing their IPv6 addresses. 332 o When using the optional DAD mechanism of Section 8.2 6LRs either 333 register with all the 6LBRs, or the network uses some out-of-scope 334 mechanism to keep the 6LBRs synchronized. 336 o If IEEE 802.15.4 16-bit short addresses are used, then some 337 technique is used to ensure uniqueness of those link-layer 338 addresses. That could be done using DHCPv6 or other techniques 339 outside of the scope of this document. Optionally it can be done 340 using the Address Registration Option based duplicate address 341 detection (Specified in Section 8.2). 343 o In order to preserve the uniqueness of addresses not derived from 344 an EUI-64, they must be either assigned or checked for duplicates 345 in the same way throughout the LoWPAN. This can be done using 346 DHCPv6 for assignment and/or using the duplicate address detection 347 mechanism Specified in Section 8.2 (or any other protocol 348 developed for that purpose). 350 o In order for [I-D.ietf-6lowpan-hc] to operate correctly, the 351 compression context must match for all the hosts, 6LRs, and 6LBRs 352 that can send, receive, or forward a given packet. If Section 8.1 353 is used to distribute context information this implies that all 354 the 6LBRs must coordinate the context information they distribute. 356 o This specification describes the operation of ND within a single 357 LoWPAN. The participation of a node in multiple LoWPANs 358 simultaneously may be possible, but is out of scope of this 359 document. 361 2. Terminology 363 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 364 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 365 document are to be interpreted as described in [RFC2119]. 367 This specification requires readers to be familiar with all the terms 368 and concepts that are discussed in "Neighbor Discovery for IP version 369 6" [RFC4861] "IPv6 Stateless Address Autoconfiguration" [RFC4862], 370 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 371 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 372 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944] 373 and "IP Addressing Model in Ad Hoc Networks" 374 [I-D.ietf-autoconf-adhoc-addr-model]. 376 This specification makes extensive use of the same terminology 377 defined in [RFC4861] unless otherwise defined below. 379 6LoWPAN link: 380 A wireless link determined by single hop reachability of 381 neighboring nodes. These are considered links with undetermined 382 connectivity properties as in [I-D.ietf-autoconf-adhoc-addr-model] 384 Low-Power and Lossy Network (LLN): 385 A network made up of low-power links, often with a high 386 probability of packet loss and undetermined connectivity 387 properties. A LoWPAN is such a network for example. 389 6LoWPAN Node (6LN): 390 A 6LoWPAN Node is any host or router participating in a LoWPAN. 391 This term is used when referring to situations in which either a 392 host or router can play the role described. 394 6LoWPAN Router (6LR): 395 An intermediate router in the LoWPAN who can communicate with 396 other 6LoWPAN routers in the same LoWPAN. 6LoWPAN routers are 397 present only in route-over topologies. 399 6LoWPAN Border Router (6LBR): 400 A border router located at the junction of separate 6LoWPAN 401 networks or between a 6LoWPAN network and another IP network. 402 There may be one or more 6LBRs at the 6LoWPAN network boundary. A 403 6LBR is the responsible authority for IPv6 Prefix propagation for 404 the 6LoWPAN network it is serving. An isolated LoWPAN also 405 contains a 6LBR in the network, which provides the prefix(es) for 406 the isolated network. 408 Router: 409 Either a 6LR or a 6LBR. Note that nothing in this document 410 precludes a node bring a router on some interfaces and a host on 411 other interfaces as allowed by [RFC2460]. 413 Mesh-under: 414 A topology where hosts are connected to a 6LBR through a mesh 415 using link-layer forwarding. Thus in a mesh-under configuration 416 all IPv6 hosts in a LoWPAN are only one IP hop away from the 6LBR. 417 This topology simulates the typical IP-subnet topology with one 418 router with multiple nodes in the same subnet. 420 Route-over: 421 A configuration topology where hosts are connected to the 6LBR 422 through the use of intermediate layer-3 (IP) routing. Here hosts 423 are typically multiple IP hops away from a 6LBR. The route-over 424 topology typically consists of a 6LBR, a set of 6LRs and hosts. 426 Registration: 427 The process during which a LoWPAN node sends an Neighbor 428 Solicitation message with an Address Registration option to a 429 Router creating a Neighbor Cache entry for the LoWPAN node with a 430 specific timeout. Thus for 6LoWPAN Router the Neighbor Cache 431 doesn't behave like a cache. Instead it behaves as a registry of 432 all the host addresses that are attached to the Router. 434 3. Protocol Overview 436 The Neighbor Discovery optimizations for LLNs are applicable to both 437 mesh-under and route-over configurations. In a mesh-under 438 configuration only 6LoWPAN Border Routers and hosts exist; there are 439 no 6LoWPAN routers in mesh-under topologies. 441 The most important part of the optizations is the evolved host-to- 442 router interaction that allows for sleeping nodes and avoids using 443 multicast Neighbor Discovery messages except for the case of a host 444 finding an initial set of default routers, and redoing such 445 determination when those set of routers have become unreachable. 447 The protocol also provides for header compression 448 [I-D.ietf-6lowpan-hc] by carrying header compression information in a 449 new option in Router Advertisement messages. 451 In addition, there are optional and separate mechanisms that can be 452 used between 6LRs and 6LBRs to perform multihop Duplicate Address 453 Detection and distribution of the Prefix and compression Context 454 information from the 6LBRs to all the 6LRs, which in turn use normal 455 Neighbor Discovery mechanisms to convey this information to the 456 hosts. 458 The protocol is designed so that the host-to-router interaction is 459 not affected by the configuration of the 6LoWPAN; the host-to-router 460 interaction is the same in a mesh-under and route-over configuration. 462 3.1. Extensions to RFC4861 464 This document specifies the following optimizations and extensions to 465 IPv6 Neighbor Discovery [RFC4861]: 467 o Host initiated refresh of Router Advertisement information. This 468 removes the need for periodic or unsolicited Router Advertisements 469 from routers to hosts. 471 o No Duplicate Address Detection (DAD) is required if EUI-64 based 472 IPv6 addresses are used. 474 o DAD is optional if DHCPv6 is used to assign addresses. 476 o A New Address Registration mechanism using new Address 477 Registration option between hosts and routers. This removes the 478 need for Routers to use multicast Neighbor Solicitations to find 479 hosts, and supports sleeping hosts. This also enables the same 480 IPv6 address prefix(es) to be used across a route-over 6LoWPAN. 481 It provides the host-to-router interface for Duplicate Address 482 Detection. 484 o A new optional Router Advertisement option for Context information 485 used by 6LoWPAN header compression. 487 o A new optional mechanism to perform Duplicate Address Detection 488 across a route-over 6LoWPAN reusing the above Address Registration 489 option. 491 o New optional mechanisms to distribute Prefixes and Context 492 information across a route-over network which uses a new 493 Authoritative Border Router option to control the flooding of 494 configuration changes. 496 o A few new default protocol constants are introduced and some 497 existing Neighbor Discovery protocol constants are tuned for LLN 498 usage. 500 3.2. Address Assignment 502 Hosts in a 6LoWPAN configure their IPv6 address as specified in 503 [RFC4861] and [RFC4862] based on the information received in Router 504 Advertisement messages. The use of the M flag in this optimization 505 is however more restrictive than in [RFC4861]. When the M flag is 506 set a host is required to use DHCPv6 to assign any non-EUI-64 507 addresses. When the M flag is not set, the LoWPAN is required to 508 support duplicate address detection, thus a host can then safely use 509 the address registration mechanism to check non-EUI-64 addresses for 510 uniqueness. 512 Optionally, 6LRs can use the same mechanisms to configure their IPv6 513 addresses. 515 The 6LBRs are responsible for managing the prefix(es) assigned to the 516 6LoWPAN, using manual configuration, DHCPv6 Prefix Delegation 517 [RFC3633], or other mechanisms. In an isolated LoWPAN a ULA 518 [RFC4193] prefix SHOULD be generated by the 6LBR. 520 3.3. Host-to-Router Interaction 522 A host sends Router Solicitation messages at startup and also when it 523 suspects that one of its default routers have become unreachable 524 (after Neighbor Unreachability Detection towards the router fails). 526 Hosts receive Router Advertisement messages typically containing the 527 Authoritative Border Router option (ABRO) and may optionally contain 528 one or more 6LoWPAN Context options (6CO) in addition to the existing 529 Prefix Information options (PIO) as described in [RFC4861]. 531 When a host has configured a non-link-local IPv6 address, it 532 registers that address with one or more of its default routers using 533 the Address Registration option (ARO) in an NS message. The host 534 chooses a lifetime of the registration and repeats the ARO option 535 periodically (before the lifetime runs out) to maintain the 536 registration, even while the host is sleeping. 538 The registration can fail (an ARO option returned to the host with a 539 non-zero Status) if the router determines that the IPv6 address is 540 already used by another hosts, that is, is used by a host with a 541 different EUI-64. This can be used to support non-EUI-64 based 542 addresses such as temporary IPv6 addresses [RFC4941] or addresses 543 based on an Interface ID that is a IEEE 802.15.4 16-bit short 544 addresses. Failure can also occur if the Neighbor Cache on that 545 router is full. 547 The re-registration of a address can be combined with Neighbor 548 Unreachability Detection (NUD) of the router since both use unicast 549 Neighbor Solicitation messages. This makes things efficient when a 550 host wakes up to send a packet and both need to perform NUD to check 551 that the router is still reachable, and refresh its registration with 552 the router. 554 The response to an address registration might not be immediate since 555 in route-over configurations the 6LR might perform Duplicate Address 556 Detection against the 6LBR. A host retransmits the Address 557 Registration option until it is acknowledged by the receipt of a 558 Address Registration option. 560 As part of the optimizations, Address Resolution is not performed by 561 multicasting Neighbor Solicitation messages as in [RFC4861]. 562 Instead, the routers maintain Neighbor Cache entries for all 563 registered IPv6 addresses. If the address is not in the Neighbor 564 Cache in the router, then the address either doesn't exist, or is 565 assigned a host attached to some other router in the 6LoWPAN, or is 566 external to the 6LoWPAN. In a route-over configuration the routing 567 protocol is used to route such packets toward the destination. 569 3.4. Router-to-Router Interaction 571 The optional new router-to-router interaction is only for the route- 572 over configuration where 6LRs are present. It is optional in this 573 protocol since the functions it provides might be better provided by 574 other protocol mechanisms, be it DHCPv6, link-layer mechanisms, the 575 routing protocol, or something else. Some mechanisms from this 576 protocol might be used for router-to-router, while others are 577 provided by other protocols. For instance, context information 578 and/or prefix information might be disseminated using this protocol, 579 while Duplicate Address Detection is done using some other protocol. 581 6LRs can act like a host during system startup and prefix 582 configuration by sending Router Solicitation messages and 583 autoconfiguring their IPv6 addresses unlike routers in [RFC4861]. 585 When multihop prefix or context dissemination is used then the 6LRs 586 store the ABRO, 6CO and Prefix Information received (directly or 587 indirectly) from the 6LBRs and redistribute this information in the 588 Router Advertisement they send to other 6LRs or send to hosts in 589 response to a Router Solicitations. There is a version number field 590 in the ABRO which is used to limit the flooding of updated 591 information between the 6LRs. 593 Optionally the 6LRs can perform Duplicate Address Detection against 594 one or more 6LBRs using a special form of the Address Registration 595 option. In this case, the Neighbor Solicitation and Advertisement 596 messages will be forwarded between the 6LR and 6LBRs and the 597 [RFC4861] rule for checking hop-limit=255 is relaxed. Such multihop 598 DAD messages MUST NOT modify any Neighbor Cache entries on the 599 routers since we do not have the security benefits provided by the 600 hop-limit=255 check. 602 4. New Neighbor Discovery Options 604 This section defines new Neighbor Discovery message options used by 605 this specification. The Address Registration Option is mandatory, 606 whereas the Authoritative Border Router Option and 6LoWPAN Context 607 Option are optional. 609 4.1. Address Registration Option 611 The routers need to know the set of host IP addresses that are 612 directly reachable and their corresponding link-layer addresses. 613 This needs to be maintained as the radio reachability changes. For 614 this purpose an Address Registration Option (ARO) is introduced, 615 which can be included in unicast Neighbor Solicitation (NS) messages 616 sent by hosts. Thus it can be included in the unicast NS messages 617 that a host sends as part of Neighbor Unreachability Detection to 618 determine that it can still reach a default router. The ARO is used 619 by the receiving router to reliably maintain its Neighbor Cache. The 620 same option is included in corresponding Neighbor Advertisement (NA) 621 messages with a Status field indicating the success or failure of the 622 registration. This option is always host initiated. 624 The ARO is reused for the optional multihop Duplicate Address 625 Detection from 6LRs to 6LBRs, in which case it has a different 626 Length. In that case one or more AROs can be included in an NS. 628 The ARO is required for reliability and power saving. The lifetime 629 field provides flexibility to the host to register an address which 630 should be usable (continue to be advertised by the 6LR in the routing 631 protocol etc.) during its intended sleep schedule. 633 The sender of the NS also includes the EUI-64 of the interface it is 634 registering an address from. This is used as a unique ID for the 635 detection of duplicate addresses. It is used to tell the difference 636 between the same node re-registering its address and a different node 637 (with a different EUI-64) registering an address that is already in 638 use by someone else. 640 When the ARO is used by hosts the address that is registered MUST be 641 the IPv6 source address for the Neighbor Solicitation message. Thus 642 the Registered Address field is omitted and the Length field MUST be 643 two. When the ARO is used for the optional multihop DAD between a 644 6LR and a 6LBR then the Registered Address field is included and the 645 Length field MUST be four. 647 When sent in NS messages the ARO MUST be accompanied by an SLLA 648 option containing the link-layer address of the 6LN that is 649 registering the address. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length | Status | Reserved | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Registration Lifetime | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | | 659 | EUI-64 | 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | 663 + + 664 | | 665 + Registered Address (Optional) + 666 | | 667 + + 668 | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Fields: 673 Type: TBD1 675 Length: 8-bit unsigned integer. The length of the option in 676 units of 8 octets. 2 without or 4 with the Registered 677 Address. 679 Status: 8-bit unsigned integer. Indicates the status of a 680 registration in the NA response. MUST be set to 0 in 681 NS messages. See below. 683 Reserved: 8-bits. This field is unused. It MUST be initialized 684 to zero by the sender and MUST be ignored by the 685 receiver. 687 Registration Lifetime: 32-bit unsigned integer. The amount of time 688 in seconds that the router should retain the Neighbor 689 Cache entry for the sender of the NS that includes 690 this option. 692 EUI-64: 64 bits. This field is used to uniquely identify the 693 interface of the registered address. 695 Registered Address: 128-bit optional field. MUST NOT be sent by a 696 host. Used for the optional router-router 697 registrations on behalf of a host. Carries the host 698 address, which was contained in the IPv6 Source field 699 in the original NS that contained the option sent by 700 the host. 702 The Status values used in Neighbor Advertisements are: 704 +--------+--------------------------------------------+ 705 | Status | Description | 706 +--------+--------------------------------------------+ 707 | 0 | Success | 708 | 1 | Duplicate Address | 709 | 2 | Neighbor Cache Full | 710 | 3-255 | Allocated using Standards Action [RFC2434] | 711 +--------+--------------------------------------------+ 713 Table 1 715 4.2. 6LoWPAN Context Option 717 The optional 6LoWPAN Context Option (6CO) carries prefix information 718 for LoWPAN header compression, and is similar to the Prefix 719 Information Option of [RFC4861]. However, the prefixes can be remote 720 as well as local to the LoWPAN since header compression potentially 721 applies to all IPv6 addresses. This option allows for the 722 dissemination of multiple contexts identified by a Context Identifier 723 (CID) for use as specified in [I-D.ietf-6lowpan-hc]. A context may 724 be a prefix of any length or an address (/128), and up to 16 6LoWPAN 725 Context options may be carried in an Router Advertisement message. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Type | Length |Context Length | Res |C| CID | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Valid Lifetime | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 . . 735 . Context Prefix . 736 . . 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 1: 6LoWPAN Context Option format 741 Type: TBD2 743 Length: 8-bit unsigned integer. The length of the option (including 744 the type and length fields) in units of 8 octets. May be 2 or 3 745 depending on the length of the Context Prefix field. 747 Context Length: 8-bit unsigned integer. The number of leading bits 748 in the Context Prefix field that are valid. The value ranges from 749 0 to 128. If it is more than 64 then the Length MUST be 3. 751 C: 1-bit context compression flag. This flag indicates if the 752 context is valid for use in compression. A context that is not 753 valid MUST NOT be used for compression, but SHOULD be used in 754 decompression in case another compressor has not yet received the 755 updated context information. This flag is used to manage the 756 context lifecycle based on the recommendations in Section 7.2. 758 CID: 4-bit Context Identifier for this prefix information. CID is 759 used by context based header compression specified in 760 [I-D.ietf-6lowpan-hc]. The list of CIDs for a LoWPAN is 761 configured by on the 6LBR that originates the context information 762 for the 6LoWPAN. 764 Res: 3-bit reserved field. This field is unused. It MUST be 765 initialized to zero by the sender and MUST be ignored by the 766 receiver. 768 Valid Lifetime: 32-bit unsigned integer. The length of time in 769 seconds (relative to the time the packet is received) that the 770 context is valid for the purpose of header compression or 771 decompression. A value of all one bits (0xffffffff) represents 772 infinity. A value of all zero bits (0x0) indicates that this 773 context entry MUST be removed immediately. 775 Context Prefix: The IPv6 prefix or address corresponding to the 776 Context ID (CID) field. The valid length of this field is 777 included in the Context Length field. This field is padded with 778 zeros in order to make the option a multiple of 8-bytes. 780 4.3. Authoritative Border Router Option 782 The optional Authoritative Border Router Option (ABRO) is needed when 783 Router Advertisement (RA) messages are used to disseminate prefixes 784 and context information across a route-over topology. In this case 785 6LRs receive Prefix Information options from other 6LRs. This 786 implies that a 6LR can't just let the most recently received RA win. 787 In order to be able to reliably add and remove prefixes from the 788 6LoWPAN we need to carry information from the authoritative 6LBR. 789 This is done by introducing a version number which the 6LBR sets and 790 6LRs propagate as they propagate the prefix and context information 791 with this Authoritative Border Router Option. When there are 792 multiple 6LBRs they would have separate version number spaces. Thus 793 this option needs to carry the IP address of the 6LBR that originated 794 that set of information. 796 The Authoritative Border Router option MUST be included in all Router 797 Advertisement messages in the case when Router Advertisements are 798 used to propagate information between routers (as described in 799 Section 8.2. 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Type | Length = 3 | Reserved | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Version Number | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 + + 810 | | 811 + 6LBR Address + 812 | | 813 + + 814 | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Fields: 819 Type: TBD3 821 Length: 8-bit unsigned integer. The length of the option in 822 units of 8 octets. Always 3. 824 Reserved: 16-bits. This field is unused. It MUST be 825 initialized to zero by the sender and MUST be ignored 826 by the receiver. 828 Version Number: 32-bit unsigned integer. The version number 829 corresponding to this set of information contained in 830 the RA message. The authoritative 6LBR originating 831 the prefix increases this version number each time its 832 set of prefix or context information changes. 834 6LBR Address: IPv6 address of the 6LBR that is the origin of the 835 included version number. 837 5. Host Behavior 839 Hosts in a LoWPAN use the Address Registration option in the Neighbor 840 Solicitation messages they send as a way to maintain the Neighbor 841 Cache in the routers thereby removing the need for multicast Neighbor 842 Solicitations to do address resolution. Unlike in [RFC4861] the 843 hosts initiate updating the information they receive in Router 844 Advertisements by sending Router Solicitations before the information 845 expires. Finally, when Neighbor Unreachability Detection indicates 846 that one or all default routers have become unreachable, then the 847 host uses Router Solicitations to find a new set of default routers. 849 5.1. Forbidden Actions 851 A host in a 6LoWPAN MUST NOT accept a Redirect message. Redirect 852 messages are problematic on a link with non-transitive reachability. 854 A host would never multicast a Neighbor Solicitation message. 856 5.2. Interface Initialization 858 When the interface on a host is initialized it follows the 859 specification in [RFC4861]. A link-local address is formed based on 860 the EUI-64 assigned to the interface, and then the host sends Router 861 Solicitation messages as described in [RFC4861] Section 6.3.7. 863 There is no need to join the Solicited-Node multicast address since 864 nobody multicasts Neighbor Solicitations in this type of network. A 865 host MUST join the all-nodes multicast address. 867 5.3. Sending a Router Solicitation 869 The Router Solicitation is formatted as specified in [RFC4861] and 870 sent to the IPv6 All-Routers multicast address (see [RFC4861] Section 871 6.3.7 for details). A SLLA option MUST be included to enable unicast 872 Router Advertisements in response. An unspecified source address 873 MUST NOT be used in RS messages. 875 If the link layer supports a way to send packets to some kind of all- 876 routers anycast link-layer address, then that MAY be used to convey 877 theses packets to a router. 879 Since hosts do not depend on multicast Router Advertisements to 880 discover routers, the hosts need to intelligently retransmit Router 881 Solicitations whenever the default router list is empty, default 882 routers are unreachable, or the lifetime of the prefixes and contexts 883 in the previous RA are about to expire. The RECOMMENDED 884 retransmissions it to initially send up to 3 (MAX_RTR_SOLICITATIONS) 885 RS messages separated by at least 10 seconds 886 (RTR_SOLICITATION_INTERVAL) as specified in [RFC4861], and then 887 switch to slower retransmissions. After the initial retransmissions 888 the host SHOULD do binary exponential backoff of the retransmission 889 timer for each subsequent retransmission. However, it is useful to 890 have a maximum retransmission timer of 60 seconds 891 (MAX_RTR_SOLICITATION_INTERVAL). In all cases the RS retransmissions 892 are terminated when a RA is received. 894 5.4. Processing a Router Advertisement 896 The processing of Router Advertisements is as in [RFC4861] with the 897 addition of handling the 6LoWPAN Context option and triggering 898 address registration when a new address has been configured. 899 Furthermore, the SLLA option MUST be included in the RS. 901 Should the host erroneously receive a Prefix Information option with 902 the 'L' (on-link) flag set, then that Prefix Information Option (PIO) 903 MUST be ignored. 905 5.4.1. Address configuration 907 Address configuration follows [RFC4862]. For an address not derived 908 from an EUI-64, the M flag of the RA determines how the address can 909 be configured. If the M flag is set in the RA, then DHCPv6 MUST be 910 used to assign the address. If the M flag is not set, then the 911 address can be configured by any other means (and duplicate detection 912 is performed as part of the registration process). 914 Once an address has been configured it will be registered by 915 unicasting a Neighbor Solicitation with the Address Registration 916 option to one or more routers. 918 5.4.2. Storing Contexts 920 The host maintains a conceptual data structure for the context 921 information it receives from the routers, which is called the Context 922 Table. This includes the Context ID, the prefix (from the Context 923 Prefix field in the 6CO), the Compression bit, and the Valid 924 Lifetime. A Context Table entry that has the Compression bit clear 925 is used for decompression when receiving packets, but MUST NOT be 926 used for compression when sending packets. 928 When a 6CO option is received in a Router Advertisement it is used to 929 add or update the information in the Context Table. If the Context 930 ID field in the 6CO matches an existing Context Table entry, then 931 that entry is updated with the information in the 6CO. If the Valid 932 Lifetime field in the 6CO is zero, then the entry is immediately 933 deleted. 935 If there is no matching entry in the Context Table, and the Valid 936 Lifetime field is non-zero, then a new context is added to the 937 Context Table. The 6CO is used to update the created entry. 939 When the 6LBR changes the context information a host might not 940 immediately notice. And in the worst case a host might have stale 941 context information. For this reason 6LBRs use the recommendations 942 in Section 7.2 for carefully managing the context lifecycle. 944 5.4.3. Maintaining Prefix and Context Information 946 The prefix information is timed out as specified in [RFC4861]. When 947 the Valid Lifetime for a Context Table entry expires the entry is 948 deleted. 950 A host should inspect the various lifetimes to determine when it 951 should next initiate sending a Router Solicitation to ask for any 952 updates to the information. The lifetimes that matter are the 953 Default Router lifetime, the Valid Lifetime in the Prefix Information 954 options, and the Valid Lifetime in the 6CO. The host SHOULD unicast 955 one or more Router Solicitations to the router well before the 956 minimum of those lifetimes (across all the prefixes and all the 957 contexts) expire, and switch to multicast RS messages if there is no 958 response to the unicasts. The retransmission behavior for the Router 959 Solicitations is specified in section Section 5.3. 961 5.5. Registration and Neighbor Unreachability Detection 963 Unicast Neighbor Solicitation (NS) messages are sent by hosts to 964 register their IPv6 addresses, and also to do NUD to verify that its 965 default routers are still reachable. The registration is performed 966 by the host including an ARO in the Neighbor Solicitation it sends. 967 Even if the host doesn't have data to send, but is expecting others 968 to try to send packets to the host, the host needs to maintain its 969 Neighbor Cache entries in the routers. This is done by sending NS 970 messages with the ARO to the router well in advance of the 971 registration lifetime expiring. NS messages are retransmitted up to 972 MAX_UNICAST_SOLICIT times using a minimum timeout of RETRANS_TIMER 973 until the host receives an Neighbor Advertisement message with an ARO 974 option. 976 Hosts that receive Router Advertisement messages from multiple 977 default routers SHOULD attempt to register with more than one of them 978 in order to increase the robustness of the network. 980 Note that Neighbor Unreachability Detection probes can be suppressed 981 if by Reachability Confirmations from transport protocols or 982 applications as specified in [RFC4861]. 984 5.5.1. Sending a Neighbor Solicitation 986 The host triggers sending Neighbor Solicitation (NS) messages 987 containing an ARO when a new address is configured, when it discovers 988 a new default router, or well before the Registration Lifetime 989 expires. Such an NS MUST include a Source Link-Layer Address (SLLA) 990 option, since the router needs to record the link-layer address of 991 the host. An unspecified source address MUST NOT be used in NS 992 messages. 994 5.5.2. Processing a Neighbor Advertisement 996 A host handles Neighbor Advertisement messages as specified in 997 [RFC4861], with added logic described in this section for handling 998 the Address Registration option. 1000 In addition to the normal validation of a Neighbor Advertisement and 1001 its options, the Address Registration option is verified as follows 1002 (if present). If the Length field is not two, the option is silently 1003 ignored. If the EUI-64 field does not match the EUI-64 of the 1004 interface, the option is silently ignored. 1006 If the status field is zero, then the address registration was 1007 successful. The host saves the Registration Lifetime from the 1008 Address Registration option for use to trigger a new NS well before 1009 the lifetime expires. If the Status field is not equal to zero, the 1010 address registration has failed. 1012 5.5.3. Recovering from Failures 1014 The procedure for maintaining reachability information about a 1015 neighbor is the same as in [RFC4861] Section 7.3 with the exception 1016 that address resolution is not performed. 1018 The address registration procedure may fail for two reasons: no 1019 response to Neighbor Solicitations is received (NUD failure), or an 1020 Address Registration option with a failure Status (Status > 0) is 1021 received. In the case of NUD failure the entry for that router will 1022 be removed thus address registration is no longer of importance. 1023 When an Address Registration option with a non-zero Status field is 1024 received this indicates that registration for that address has 1025 failed. A failure Status of one indicates that a duplicate address 1026 was detected and the procedure described in [RFC4862] Section 5.4.5 1027 is followed. The host MUST NOT use the address it tried to register. 1028 If the host has valid registrations with other routers, these MUST be 1029 removed by registering with each using a zero ARO lifetime. 1031 A Status code of two indicated that the Neighbor Cache of that router 1032 is full. In this case the host SHOULD remove this router from its 1033 default router list and attempt to register with another router. If 1034 the host has no more default routers it needs to revert to sending 1035 Router Solicitations as specified in section Section 5.3. 1037 Other failure codes may be defined in future documents. 1039 5.6. Next-hop Determination 1041 The IP address of the next-hop for a destination is determined as 1042 follows. Destinations to the link-local prefix (FE80::) are always 1043 sent on the link to that destination. All other prefixes are assumed 1044 to be off-link [I-D.ietf-autoconf-adhoc-addr-model]. Anycast 1045 addresses are always considered to be off-link. They are therefore 1046 sent to one of the routers in the Default Router List. 1048 Multicast addresses are considered to be on-link and are resolved as 1049 specified in [RFC4944] or the appropriate IP-over-foo document. 1051 A LoWPAN Node is not required to maintain a minimum of one buffer per 1052 neighbor as specified in [RFC4861], since packets are never queued 1053 while waiting for address resolution. 1055 5.7. Address Resolution 1057 The address registration mechanism and the SLLA option in Router 1058 Advertisement messages provide sufficient a priori state in routers 1059 and hosts to resolve an IPv6 address to its associated link-layer 1060 address. As all prefixes but the link-local prefix are always 1061 assumed to be off-link, multicast-based address resolution between 1062 neighbors is not needed. 1064 Link-layer addresses for neighbors are stored in Neighbor Cache 1065 entries [RFC4861] In order to achieve LoWPAN compression, most global 1066 addresses are formed using a link-layer address. Thus a host can 1067 minimize memory usage by optimizing for this case and only storing 1068 link-layer address information if it differs from the link-layer 1069 address corresponding to the Interface ID of the IPv6 address (i.e., 1070 differs in more than the on-link/global bit being inverted). 1072 5.8. Sleeping 1074 It is often advantageous for battery-powered hosts in LoWPANs to keep 1075 a low duty cycle. The optimizations described in this document 1076 enable hosts to sleep as described further in this section. Routers 1077 may want to cache traffic destined to a host which is sleeping, but 1078 such functionality is out of the scope of this document. 1080 5.8.1. Picking an Appropriate Registration Lifetime 1082 As all Neighbor Discovery messages are initiated by the hosts, this 1083 allows a host to sleep or otherwise be unreachable between NS 1084 messages. The Address Registration option attached to NS messages 1085 indicates to a router to keep the Neighbor Cache entry for that 1086 address valid for the period in the Registration Lifetime field. A 1087 host should choose a sleep time appropriate for its energy 1088 characteristics, and set a registration lifetime larger than the 1089 sleep time to ensure the registration is renewed successfully 1090 (considering e.g. clock drift). A host should also consider the 1091 stability of the network (how quickly the topology changes) when 1092 choosing its sleep time (and thus registration lifetime). A dynamic 1093 network may require a shorter sleep time. 1095 5.8.2. Behavior on Wakeup 1097 When a host wakes up from a sleep period it SHOULD maintain its 1098 current address registrations that will timeout before the next 1099 wakeup. This is done by sending Neighbor Solicitation messages with 1100 the Address Registration option as described in Section 5.5.1. The 1101 host may also need to refresh its prefix and context information by 1102 sending new unicast Router Solicitation. If after wakeup the host 1103 (using NUD) determines that some or all previous default routers have 1104 become unreachable, then the host will restart doing multicast Router 1105 Solicitations to discover new default router(s) and restart the 1106 address registration process. 1108 6. Router Behavior for 6LR and 6LBR 1110 Both 6LRs and 6LBRs maintain the Neighbor Cache [RFC4861] based on 1111 the Address Registration Options they receive in Neighbor 1112 Advertisement messages from hosts. Note that the handling of ARO 1113 from other routers (with Length=4) is specified in Section 8. 1115 The routers SHOULD NOT garbage collect the Neighbor Cache entries 1116 since they need to retain them until the Registration Lifetime 1117 expires. Similarly, if Neighbor Unreachability Detection on the 1118 router determines that the a host is UNREACHABLE (based on the logic 1119 in [RFC4861]), the Neighbor Cache entry SHOULD NOT be deleted but be 1120 retained until the Registration Lifetime expires. A renewed ARO 1121 should mark the cache entry as STALE. Thus for 6LoWPAN Routers the 1122 Neighbor Cache doesn't behave like a cache. Instead it behaves as a 1123 registry of all the host addresses that are attached to the Router. 1125 Routers MAY implement the Default Router Preferences [RFC4191] and 1126 use that to indicate to the host whether the router is a 6LBR or a 1127 6LR. If this is implemented then 6LRs with no route to a border 1128 router MUST set Prf to (11) for low preference, other 6LRs MUST set 1129 Prf to (00) for normal preference, and 6LBRs MUST set Prf to (01) for 1130 high preference. 1132 6.1. Forbidden Actions 1134 A router SHOULD NOT send Redirect messages. Since the link has non- 1135 transitive reachability the router has no way to determine that the 1136 recipient of a Redirect message can reach the link-layer address. 1138 A router MUST NOT set the 'L' (on-link) flag in the Prefix 1139 Information options, since that might trigger hosts to send multicast 1140 Neighbor Solicitations. 1142 6.2. Interface Initialization 1144 A router initializes its interface more or less as in [RFC4861]. 1145 However, a 6LR might want to wait to make its interfaces advertising 1146 (implicitly keeping the AdvSendAdvertisements flag clear) until it 1147 has received the prefix(es) and context information from its 6LBR. 1148 That is independent of whether prefixes and context information is 1149 disseminated using the methods specified in this document, or using 1150 some other method. 1152 6.3. Processing a Router Solicitation 1154 A router processes Router Solicitation messages as specified in 1155 [RFC4861]. The differences relate to the inclusion of Authoritative 1156 Border Router options in the Router Advertisement (RA) messages. If 1157 a 6LR has received an ABRO from a 6LBR, then it will include that 1158 option unmodified in the Router Advertisement messages it sends. And 1159 if the 6LR has received RAs, whether with the same prefixes and 1160 context information or different, from different 6LBR, then it will 1161 need to keep those prefixes and context information separately so 1162 that the RAs the 6LR sends will maintain the association between the 1163 ABRO and the prefixes and context information. The router can tell 1164 which 6LBR originated the prefixes and context information from the 1165 6LBR Address field in the ABRO. When a router has information tied 1166 to multiple ABROs, a single RS will result in multiple RAs each 1167 containing a different ABRO. 1169 A Router Solicitation might be received from a host that has not yet 1170 registered its address with the router. Thus the router MUST NOT 1171 modify its Neighbor Cache with the SLLA option from the Router 1172 Solicitation. The SLLA option is only used to form the link-layer 1173 address to which the router sends the Router Advertisement. 1175 A 6LR or 6LBR MUST include a Source Link-layer address option in the 1176 Router Advertisements it sends. That is required so that the hosts 1177 will know the link-layer address of the router. 1179 6.4. Periodic Router Advertisements 1181 A router does not need to send any periodic Router Advertisement 1182 messages since the hosts will solicit updated information by sending 1183 Router Solicitations before the lifetimes expire. 1185 However, if the routers use Router Advertisements to optionally 1186 distribute prefix and/or context information across a route-over 1187 topology, that might require periodic Router Advertisement messages. 1188 Such RAs are sent using the configurable MinRtrAdvInterval and 1189 MaxRtrAdvInterval as per [RFC4861]. 1191 6.5. Processing a Neighbor Solicitation 1193 A router handles Neighbor Solicitation messages as specified in 1194 [RFC4861], with added logic described in this section for handling 1195 the Address Registration option. 1197 In addition to the normal validation of a Neighbor Solicitation and 1198 its options, the Address Registration option is verified as follows 1199 (if present). If the Length field is not two, or if the Status field 1200 is not zero, then the Neighbor Solicitation is silently ignored. 1201 Note that Section 8.2 specify optional behavior for a 6LBR for other 1202 Length field values. 1204 If the source address of the NS is the unspecified address, or if no 1205 SLLA option is included, then any included ARO is ignored, that is, 1206 the NS is processed as if it did not contain an ARO. 1208 6.5.1. Checking for Duplicates 1210 If the NS contains a valid ARO, then the router inspects its Neighbor 1211 Cache on the arriving interface to see if it is a duplicate. If 1212 there is no Neighbor Cache entry for the IPv6 source address of the 1213 NS, then it isn't a duplicate. If there is such a Neighbor Cache 1214 entry and the EUI-64 is the same, then it isn't a duplicate either. 1215 Otherwise it is a duplicate address. 1217 In the case it is a duplicate address then the router responds with a 1218 unicast Neighbor Advertisement (NA) message sent to the source link- 1219 layer address (from the Source Link-Layer Address (SLLA) option) of 1220 the NS. The NA is formatted with a copy of the ARO from the NS, but 1221 with the Status field set to one to indicate it was a duplicate. In 1222 this case there is no modification to the Neighbor Cache. 1224 6.5.2. Updating the Neighbor Cache 1226 If ARO did not result in a duplicate address being detected as above, 1227 then if the Registration Lifetime is non-zero the router creates (if 1228 it didn't exist) or updates (otherwise) a Neighbor Cache entry for 1229 the IPv6 source address of the NS. If the Neighbor Cache is full and 1230 a new entry needs to be created, then the router responds with a 1231 unicast NA sent to source link-layer address (from the Source Link- 1232 Layer Address (SLLA) option) of the NS. The NA is formatted with a 1233 copy of the ARO from the NS, but with the Status field set to two to 1234 indicate the router's Neighbor Cache is full. 1236 The Registration Lifetime and the EUI-64 are recorded in the Neighbor 1237 Cache entry. A unicast Neighbor Advertisement (NA) is then sent in 1238 response to the NS. This NA SHOULD include a copy of the ARO, with 1239 the Status field set to zero. 1241 If the ARO contains a zero Registration Lifetime then any existing 1242 Neighbor Cache entry for the IPv6 source address of the NS MUST be 1243 deleted, and a NA sent as above. 1245 Should the Registration Lifetime in a Neighbor Cache entry expire, 1246 then the router MUST delete the cache entry. This might result in 1247 notifying the routing protocol. 1249 Note: If the optional multihop DAD (section Section 8.2) is used, the 1250 a 6LR MUST NOT create a Neighbor Cache entry until the multihop DAD 1251 is completed. 1253 6.5.3. Address Resolution between Routers 1255 There needs to be a mechanism somewhere for the routers to discover 1256 each other's link-layer addresses. If the routing protocol used 1257 between the routers provides this, then there is no need for the 1258 routers to use the Address Registration option between each other. 1259 Otherwise, the routers MAY use the ARO. When routers use ARO to 1260 register with each other and the optional DAD to the 6LBR Section 8.2 1261 is in use, then care should be taken to ensure that there isn't a 1262 flood of ARO-carrying messages send to the 6LBR as each router hears 1263 an ARO from their neighboring routers. The details for this is out 1264 of scope of this document. 1266 6.5.4. Neighbor Unreachability Detection 1268 Just like in [RFC4861] the use of NUD from routers to hosts is 1269 required. NUD may also be used between routers, but is not required 1270 if an equivalent mechanism is available, for example, as part of the 1271 routing protocols. 1273 7. Border Router Behavior 1275 A 6LBR handles sending of Router Advertisements and processing of 1276 Neighbor Solicitations from hosts as specified above in section 1277 Section 6. A 6LBR SHOULD always include an Authoritative Border 1278 Router option in the Router Advertisements it sends, listing itself 1279 as the 6LBR Address. That requires that the 6LBR maintain the 1280 version number in stable storage, and increases the version number 1281 when some information in its Router Advertisements change. The 1282 information whose change affects the version are in the Prefix 1283 Information options (the prefixes or their lifetimes) and in the 6CO 1284 option (the prefixes, Context IDs, or lifetimes.) 1286 In addition, a 6LBR is somehow configured with the prefix or prefixes 1287 that are assigned to the LoWPAN, and advertises those in Router 1288 Advertisements as in [RFC4861]. Optionally, in the case of route- 1289 over, those prefixes can be disseminated to all the 6LRs using the 1290 technique in Section 8.1. However, there might be mechanisms outside 1291 of the scope of this document that can be used instead for prefix 1292 dissemination with route-over. 1294 If the 6LoWPAN uses Header Compression [I-D.ietf-6lowpan-hc] then the 1295 6LBR needs to manage the context IDs, and advertise those in Router 1296 Advertisements by including 6CO options in its Router Advertisements 1297 so that directly attached hosts are informed about the context IDs. 1298 Below we specify things to consider when the 6LBR needs to add, 1299 remove, or change the context information. Optionally, in the case 1300 of route-over, the context information can be disseminated to all the 1301 6LRs using the technique in Section 8. However, there might be 1302 mechanisms outside of the scope of this document that can be used 1303 instead for disseminating context information with route-over. 1305 7.1. Prefix Determination 1307 The prefix or prefixes used in a LoWPAN can be manually configured, 1308 or can be acquired using DHCPv6 Prefix Delegation [RFC3633]. For a 1309 LoWPAN that is isolated from the network, either permanently or 1310 occasionally, the 6LBR can assign a ULA prefix using [RFC4193]. The 1311 ULA prefix should be stored in stable storage so that the same prefix 1312 is used after a failure of the 6LBR. If the LoWPAN has multiple 1313 6LBRs, then they should be configured with the same set of prefixes. 1314 The set of prefixes are included in the Router Advertisement messages 1315 as specified in [RFC4861]. 1317 7.2. Context Configuration and Management 1319 If the LoWPAN uses Header Compression [I-D.ietf-6lowpan-hc] then the 1320 6LBR may be configured with context information and related context 1321 IDs. If the LoWPAN has multiple 6LBRs, then they MUST be configured 1322 with the same context information and context IDs. 1324 The context information carried in Router Advertisement (RA) messages 1325 originate at 6LBRs and must be disseminated to all the routers and 1326 hosts within the LoWPAN. RAs include one 6CO for each context. 1328 For the dissemination of context information using the 6CO, a strict 1329 lifecycle SHOULD be used in order to ensure the context information 1330 stays synchronized throughout the LoWPAN. New context information 1331 SHOULD be introduced into the LoWPAN with C=0, to ensure it is known 1332 by all nodes that may have to decompress based on this context 1333 information. Only when it is reasonable to assume that this 1334 information was successfully disseminated SHOULD an option with C=1 1335 be sent, enabling the actual use of the context information for 1336 compression. 1338 Conversely, to avoid that nodes send packets making use of previous 1339 values of contexts, resulting in ambiguity when receiving a packet 1340 that uses a recently changed context, old values of a context SHOULD 1341 be taken out of use for a while before new values are assigned to 1342 this specific context. That is, in preparation for a change of 1343 context information, its dissemination SHOULD continue for at least 1344 MIN_CONTEXT_CHANGE_DELAY with C=0. Only when it is reasonable to 1345 assume that the fact that the context is now invalid was successfully 1346 disseminated, should the context ID be taken out of dissemination or 1347 reused with a different Context Prefix field. In the latter case, 1348 dissemination of the new value again SHOULD start with C=0, as above. 1350 8. Optional Behavior 1352 Optionally the Router Advertisement messages can be used to 1353 disseminate prefixes to all the 6LRs in a route-over topology. This 1354 is optional because there are likely to be other mechanisms for such 1355 information distribution. 1357 There is also the option to reuse the Address Registration option as 1358 a way for a 6LR to perform DAD (for non-EUI-64 derived IPv6 1359 addresses) against a 6LBR in a route-over topology. This is optional 1360 because there might be other ways to either allocate unique address, 1361 such as DHCPv6 [RFC3315], or other future mechanisms for DAD. 1363 8.1. Multihop Prefix and Context Distribution 1365 The multihop distribution relies on Router Solicitation messages and 1366 Router Advertisement (RA) messages sent between routers, and using 1367 the ABRO version number to control the propagation of the information 1368 (prefixes and context information) that is being sent in the RAs. 1370 This multihop distribution mechanism can handle arbitrary information 1371 from an arbitrary number of 6LBRs. However, the semantics of the 1372 context information requires that all the 6LNs use the same 1373 information, whether they send, forward, or receive compressed 1374 packets. Thus the manager of the 6LBRs need to somehow ensure that 1375 the context information is in synchrony across the 6LBRs. This can 1376 be handled in different ways. One possible way to ensure it is to 1377 treat the context and prefix information as originating from some 1378 logical or virtual source, which in essence means that it looks like 1379 the information is distributed from a single source. 1381 If a set of 6LBRs behave as a single one (using mechanisms out of 1382 scope of this document) so that the prefixes and contexts and ABRO 1383 version number will be the same from all the 6LBRs, then those 6LBRs 1384 can pick a single IP address to use in the ABRO option. 1386 8.1.1. 6LBRs Sending Router Advertisements 1388 6LBRs supporting multihop prefix and context distribution MUST 1389 include an ABRO in each of its RAs. The ABRO Version field is used 1390 to keep prefix and context information consistent throughout the 1391 LoWPAN along with the guidelines in Section 7.2. Each time any 1392 information in the set of PIO or 6CO options change, the ABRO Version 1393 is increased by one. 1395 This requires that the 6LBR maintain the PIO, 6CO, and ABRO Version 1396 in stable storage, since an old version number will be silently 1397 ignored by the 6LRs. 1399 8.1.2. Routers Sending Router Solicitations 1401 If multihop distribution is done using Router Advertisement (RA) 1402 messages, then on interface initialization a router SHOULD send some 1403 Router Solicitation messages similarly to how hosts do this in 1404 [RFC4861]. That will cause the routers to respond with RA messages 1405 which then can be used to initially seed the prefix and context 1406 information. 1408 8.1.3. Routers Processing Router Advertisements 1410 If multihop distribution is not done using RA messages, then the 1411 routers follow [RFC4861] which states that they merely do some 1412 consistency checks and nothing in Section 8.1 applies. Otherwise the 1413 routers will check and record the prefix and context information from 1414 the receive RAs, and use that information as follows. 1416 If a received RA does not contain a Authoritative Border Router 1417 option, then the RA MUST be silently ignored. 1419 The router uses the 6LBR Address field in the ABRO to check if it has 1420 previously received information from the 6LBR. If it finds no such 1421 information, then it just records the 6LBR Address and Version and 1422 the associated prefixes and context information. If the 6LBR is 1423 previously known, then the Version number field MUST be compared 1424 against the recorded version number for that 6LBR. The comparison 1425 MUST be done the same way as TCP sequence number comparisons to 1426 handle the case when the version number wraps around. If the 1427 received version number is older or the same as the recorded version, 1428 then the information in the RA is silently ignored. Otherwise the 1429 recorded information and version number are updated. 1431 By TCP sequence number comparison we mean that half of the version 1432 number space is "old" and half is "new". For example, if the current 1433 version number is 0x2, then anything between 0x80000003 (0x2- 1434 0x7fffffff) and 0x1 is old, and anything between 0x3 and 0x80000002 1435 (0x2+0x8000000) is new. 1437 8.1.4. Storing the Information 1439 The router keeps state for each 6LBR that it sees with an ABRO. This 1440 includes the version number, and the complete set of Prefix 1441 Information options and 6LoWPAN Context options. The prefixes are 1442 timed out based on the Valid lifetime in the Prefix Information 1443 Option. The Context Prefix is timed out based on the Valid lifetime 1444 in the 6LoWPAN Context option. 1446 While the prefixes and context information are stored in the router 1447 their valid and preferred lifetimes are decremented as time passes. 1448 This ensures that when the router is in turn later advertising that 1449 information in the Router Advertisements it sends, the 'expiry time' 1450 doesn't accidentally move further into the future. For example, if a 1451 6CO with a Valid lifetime of 10 minutes is received at time T, and 1452 the router includes this in a RA it sends at time T+5 minutes, the 1453 Valid lifetime in the 6CO it sends will be only 5 minutes. 1455 8.1.5. Sending Router Advertisements 1457 If multihop distribution is performed using RA messages, then the 1458 routers MUST ensure that the ABRO always stay together with the 1459 prefixes and context information received with that ABRO. Thus if 1460 the router has received prefix P1 with ABRO saying it is from one 1461 6LBR, and prefix P2 from another 6LBR, then the router MUST NOT 1462 include the two prefixes in the same RA message. Prefix P1 MUST be 1463 in a RA that include a ABRO from the first 6LBR etc. Note that 1464 multiple 6LBRs might advertise the same prefix and context 1465 information, but they still need to be associated with the 6LBRs that 1466 advertised them. 1468 The routers periodically send Router Advertisements as in [RFC4861]. 1469 This is for the benefit of the other routers receiving the prefixes 1470 and context information. And the routers also respond to Router 1471 Solicitations by unicasting RA messages. In both cases the above 1472 constraint of keeping the ABRO together with 'its' prefixes and 1473 context information apply. 1475 When a router receives new information from a 6LBR, that is, either 1476 it hears from a new 6LBR (a new 6LBR Address in the ABRO) or the ABRO 1477 version number of an existing 6LBR has increased, then it is useful 1478 to send out a few triggered updates. The recommendation is to behave 1479 the same as when an interface has become an advertising interface in 1480 [RFC4861], that is, send up to three RA messages. This ensures rapid 1481 propagation of new information to all the 6LRs. 1483 8.2. Duplicate Address Detection 1485 The ARO can be used, in addition to registering an address in a 6LR, 1486 to have the 6LR verify that the address isn't used by some other 1487 host. However, that isn't sufficient in a route-over topology (or 1488 any LoWPAN with multiple 6LBRs) since some host attached to another 1489 6LR could be using the same address. There might be different ways 1490 for the 6LRs to coordinate such Duplicate Address Detection in the 1491 future, or addresses could be assigned using a DHCPv6 server that 1492 verifies uniqueness as part of the assignment. 1494 This specification offers an optional and simple technique for 6LRs 1495 and 6LBRs to perform Duplicate Address Detection that reuses the 1496 Address Registration option. This technique is not needed when the 1497 Interface ID in the address is based on an EUI-64, since those are 1498 assumed to be globally unique. The technique assumes that the 6LRs 1499 either register with all the 6LBRs, or that the network uses some 1500 out-of-scope mechanism to keep the DAD tables in the 6LBRs 1501 synchronized. 1503 The multihop DAD mechanism is used synchronously the first time an 1504 address is registered. That is, the ARO option is not returned to 1505 the host until multihop DAD has been completed against the 6LBRs. 1506 For existing registrations in the 6LR the multihop DAD needs to be 1507 repeated agains the 6LBRs to ensure that the entry for the address in 1508 the 6LBRs does not time out, but that can be done asynchronously with 1509 the response to the hosts. For instance, by tracking how much is 1510 left of the lifetime the 6LR registered with the 6LBRs. 1512 For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor 1513 Cache entry for the address until it receives a successful ARO option 1514 from the 6LBRs. Otherwise a duplicate could end up being registered 1515 in the 6LRs Neighbor Cache which would cause a registration from the 1516 original host with this 6LR to fail. The system "remembers" the 1517 link-layer address of the host by carrying the host's SLLA option in 1518 the multihop DAD messages, and that is used to later deliver the NA 1519 with the ARO back to the host. 1521 When a 6LR receives a Neighbor Solicitation containing an Address 1522 Registration option with a non-zero Registration Lifetime and is has 1523 no existing Neighbor Cache entry, then with this mechanism it will 1524 invoke synchronous multihop DAD. 1526 The 6LR will unicast a new Neighbor Solicitation message to one or 1527 more 6LBRs, where the NS contains an ARO with the host's address in 1528 the Registered Address field, and the SLLA option that the host 1529 included in its NS. This NS will be forwarded by 6LRs until it 1530 reaches the 6LBR, hence its IPv6 hop limit field might be less than 1531 255 when received by the 6LBR. The 6LBR will respond with a Neighbor 1532 Advertisement message containing an ARO, which might have a hop limit 1533 less than 255 when it reaches the 6LR. 1535 When the 6LR receives the NA from the 6LBR containing a successful 1536 ARO, it will create or update the Neighbor Cache entry for the host 1537 and then respond to the host with an NA, copying the Status field 1538 from the ARO it received from the 6LBR. Note that the 6LR does not 1539 create a Neighbor Cache entry until it receives a successful ARO back 1540 from a 6LBR. Instead it uses the SLLA option of the NA from the 6LBR 1541 to reach the host. 1543 8.2.1. Special Message Validation 1545 Due to the forwarding of the above special NS/NA between the 6LR and 1546 6LBR the hop limit check on receipt MUST be bypassed for such 1547 messages that contain a ARO with a Length field of 4. The receipt of 1548 such messages MUST NOT modify any state on the router with the 1549 exception of the DAD table below. 1551 8.2.2. Conceptual Data Structures 1553 A 6LBR implementing the optional multi-hop DAD needs to maintain some 1554 state separate from the Neighbor Cache. We call this conceptual data 1555 structure the DAD table. It is indexed by the IPv6 address - the 1556 Registered Address in the ARO - and contains the EUI-64 of the host 1557 that is using that address. 1559 8.2.3. 6LR Sending a special Neighbor Solicitation 1561 When a 6LR that implements the optional multihop DAD receives an NS 1562 from a host (the ARO has Length = 2) and the 6LR does not already 1563 have a Neighbor Cache entry for the host's IPv6 address, then the 6LR 1564 forms and sends an NS to at least one 6LBR. The NS contains the 1565 following information: 1567 o In the IPv6 source address, a global address of the 6LR. 1569 o In the IPv6 destination address, the address of the 6LBR. 1571 o In the IPv6 hop limit, 255 or a smaller number. 1573 o In the NS Target Address, the address of the 6LBR. 1575 o An SLLA option copied from the NS received from the host. 1577 o In the ARO the Status field MUST be set to zero 1579 o In the ARO the EUI-64 and Registration lifetime are copied from 1580 the ARO received from the host. 1582 o In the ARO and the Registered Address set to the IPv6 address of 1583 the host, that is, the sender of the triggering NS. 1585 When a 6LR receives an NS from a host with a zero Registration 1586 Lifetime then, in addition to removing the Neighbor Cache entry for 1587 the host as specified in section Section 6, an NS is sent to the 1588 6LBRs as above. 1590 A router MUST NOT modify the Neighbor Cache as a result of receiving 1591 a Neighbor Solicitation with an ARO of Length=4. 1593 8.2.4. 6LBR Receiving a special Neighbor Solicitation 1595 When a 6LBR that implements the optional multihop DAD receives an NS 1596 from a 6LR, that is an NS that contains an ARO with Length = 4, then 1597 it MUST NOT verify that the hop limit is 255 as specified above. 1598 Then it proceeds to look for the Registration Address in the DAD 1599 Table. If an entry is found and the recorded EUI-64 is different 1600 than the EUI-64 in the ARO, then it returns an NA with the ARO Status 1601 set to 1 ('Duplicate Address'). Otherwise it returns an NA with ARO 1602 Status set to zero. The SLLA option is copied from the NS to the NA, 1603 since the 6LR needs this to be able to respond to the host. 1605 If no entry is found in the DAD Table and the Registration Lifetime 1606 is non-zero, then an entry is created and the EUI-64 and Registered 1607 Address from the ARO are stored in that entry. 1609 If an entry is found in the DAD Table, the EUI-64 matches, and the 1610 Registration Lifetime is zero then the entry is deleted from the 1611 table. 1613 In both of the above cases the ARO Status code is set to zero, and 1614 the 6LBR forms an NA with the ARO and with the SLLA option copied 1615 from the NS to the NA. The NA is sent back to the 6LR i.e., back to 1616 the source of the NS. 1618 8.2.5. Processing a special Neighbor Advertisement 1620 When a 6LR that implements the optional multihop DAD receives an NA 1621 from a 6LBR, that is an NS that contains an ARO with Length = 4, then 1622 it MUST NOT verify that the hop limit is 255 as specified above. If 1623 there is no pending ARO from a host for the Registered Address, then 1624 NA is silently ignored. Otherwise, the information from the 6LBR is 1625 used to form an NA to send to the host. The Status code is copied 1626 from the ARO received from the 6LBR to the ARO that is sent to the 1627 host. 1629 If the Status is non-zero indicating an error, then the Neighbor 1630 Cache entry for the Registered Address is removed. 1632 A router MUST NOT modify the Neighbor Cache as a result of receiving 1633 a Neighbor Advertisement with an ARO of Length=4, unless there is a 1634 pending ARO for the IPv6 address and EUI-64. 1636 8.2.6. Recovering from Failures 1638 If there is no response from a 6LBR after RETRANS_TIMER [RFC4861] 1639 then the 6LR would retransmit the NS to the 6LBR up to 1640 MAX_UNICAST_SOLICIT [RFC4861] times. After this the 6LR SHOULD 1641 respond to the host with an ARO Status of zero. 1643 9. Protocol Constants 1645 This section defines the relevant protocol constants used in this 1646 document based on a subset of [RFC4861] constants. (*) indicates 1647 constants modified from [RFC4861] and (+) indicates new constants. 1649 Additional protocol constants are defined in Section Section 4. 1651 6LBR Constants: 1653 MIN_CONTEXT_CHANGE_DELAY+ 60 seconds 1655 6LR Constants: 1657 MAX_RTR_ADVERTISEMENTS 3 transmissions 1659 MIN_DELAY_BETWEEN_RAS* 10 seconds 1661 MAX_RA_DELAY_TIME* 2 seconds 1663 Host Constants: 1665 RTR_SOLICITATION_INTERVAL* 10 seconds 1667 MAX_RTR_SOLICITATIONS 3 transmissions 1669 MAX_RTR_SOLICITATION_INTERVAL+ 60 seconds 1671 10. Examples 1673 10.1. Message Examples 1675 The following diagrams show the two-step process of the optimized 1676 Neighbor Discovery mechanisms for bootstrapping and Address 1677 Registration. 1679 Node Router 1681 | | 1683 | ---------- Router Solicitation --------> | 1684 | [SLLAO] | 1686 | | 1688 | <-------- Router Advertisement --------- | 1690 | [PIO + 6CO + ABRO + SLLAO] | 1692 Figure 2: Basic Router Solicitation/Router Advertisement exchange 1693 between a node and 6LR or 6LBR 1695 Node Router 1697 | | 1699 | ------- NS with Address Registration -----> | 1701 | [ARO + SLLAO] | 1703 | | 1705 | <-----NA with Address Registration --------- | 1707 | [ARO with Status + SLLAO] | 1709 Figure 3: Neighbor Discovery Address Registration 1711 10.2. Bootstrapping Example 1713 The following example describes the address bootstrapping scenarios 1714 using the optimized ND mechanisms specified in this document. It is 1715 assumed that the 6LN first performs a sequence of operations in order 1716 to get a secure access at the link-layer of the LoWPAN and obtain a 1717 key for link-layer security. The methods of how to establish the 1718 link-layer security is out of scope of this document. In this 1719 example an IEEE 802.15.4 6LN forms a 16-bit short-address based IPv6 1720 addresses without using DHCPv6 (i.e., the M flag is not set in the 1721 Router Advertisements). 1723 1. After obtaining link-level security, a 6LN assigns a link-local 1724 IPv6 address to itself. A link-local IPv6 address is configured 1725 based on the 6LN's EUI-64 link-layer address formed as per [RFC4944]. 1727 2. Next the 6LN determines one or more default routers in the 1728 network by sending an RS to the all-routers multicast address with 1729 the SLLA Option set to its EUI-64 link-local address. If the 6LN was 1730 able to obtain the link-layer address of a router through its link- 1731 layer operations then the 6LN may form a link-local destination IPv6 1732 address for the router and send it a unicast RS. 1734 3. In order to communicate more than one IP hop away the 6LN 1735 configures a global IPv6 address. In order to save overhead, this 1736 6LN wishes to configure its IPv6 address based on a 16-bit short 1737 address as per [RFC4944]. As the network is unmanaged (M flag not 1738 set in RA), the 6LN randomly chooses a 16-bit link-layer address and 1739 forms a tentative IPv6 address from it. 1741 4. Next the 6LN registers that address with one or more of its 1742 default routers by sending a unicast NS message with an ARO 1743 containing its tentative global IPv6 address to register, the 1744 registration lifetime and its EUI-64. An SLLAO is also included with 1745 the link-layer address corresponding to the address being registered. 1746 If a successful (status 0) NA message is received the address can 1747 then be used and the 6LN assumes it has been successfully checked for 1748 duplicates. If a duplicate address (status 1) NA message is 1749 received, the 6LN then removes the temporary IPv6 address and 16-bit 1750 link-layer address and goes back to step 3. If a neighbor cache full 1751 (status 2) message is received, the 6LN attempts to register with 1752 another default router, or if none, goes back to step 2. 1754 5. The 6LN now performs maintenance by sending a new NS address 1755 registration before the lifetime expires. 1757 If multihop DAD and multihop prefix and context distribution is used, 1758 the effect of the 6LRs and hosts following the above bootstrapping is 1759 a "wavefront" of 6LRs and host being configured spreading from the 1760 6LBRs. First the hosts and 6LRs that can directly reach a 6LBR would 1761 receive one or more RAs and configure and register their IPv6 1762 addresses. Once that is done they would enable the routing protocol 1763 and start sending out Router Advertisements. That would result in a 1764 new set of 6LRs and hosts to receive responses to their Router 1765 Solicitations, form and register their addresses, etc. That repeats 1766 until all of the 6LRs and hosts have been configured. 1768 11. Security Considerations 1770 The security considerations of IPv6 Neighbor Discovery [RFC4861] 1771 apply. Additional considerations can be found in [RFC3756]. 1773 This specification expects that the link layer is sufficiently 1774 protected, for instance using MAC sublayer cryptography. In other 1775 words, model 1 from [RFC3756] applies. In particular, it is expected 1776 that the LoWPAN MAC provides secure unicast to/from Routers and 1777 secure broadcast from the Routers in a way that prevents tampering 1778 with or replaying the Router Advertisement messages. However, any 1779 future 6LoWPAN security protocol that applies to Neighbor Discovery 1780 for 6LoWPAN protocol, is out of scope of this document. 1782 The multihop DAD mechanisms rely on Neighbor Solicitation and 1783 Neighbor Advertisement messages that are forwarded by 6LRs, and as a 1784 result the hop_limit=255 check on the receiver is disabled for such 1785 messages. This implies that any node on the Internet could 1786 successfully send such messages. We avoid any additional security 1787 issues due to this by requiring that the routers never modify the 1788 Neighbor Cache entry due to such messages, and that they reject them 1789 unless they are received on an interface that has been explicitly 1790 configured to use these LLN optimizations. 1792 In some future deployments one might want to use SEcure Neighbor 1793 Discovery [RFC3971] [RFC3972]. This is possible with the Address 1794 Registration option as sent between hosts and routers, since the 1795 address that is being registered is the IPv6 source address of the 1796 Neighbor Solicitation and SeND verifies the IPv6 source address of 1797 the packet. Applying SeND to the optional router-to-router 1798 communication in this document is out of scope. 1800 12. IANA Considerations 1802 The document requires three new Neighbor Discovery option types under 1803 the subregistry "IPv6 Neighbor Discovery Option Formats": 1805 o Address Registration Option (TBD1) 1807 o 6LoWPAN Context Option (TBD2) 1809 o Authoritative Border Router Option (TBD3) 1811 [TO BE REMOVED: This registration should take place at the following 1812 location: http://www.iana.org/assignments/icmpv6-parameters] 1814 13. Acknowledgments 1816 The authors thank Pascal Thubert, Jonathan Hui, Carsten Bormann, 1817 Richard Kelsey, Geoff Mulligan, Julien Abeille, Alexandru Petrescu, 1818 Peter Siklosi, Pieter De Mil, Fred Baker, Anthony Schoofs, Phil 1819 Roberts, Daniel Gavelle, Joseph Reddy, Robert Cragie and Joakim 1820 Eriksson for useful discussions and comments that have helped shaped 1821 and improve this document. 1823 Additionally, the authors would like to recognize Carsten Bormann for 1824 the suggestions on the Context Prefix Option and contribution to 1825 earlier version of the draft, Pascal Thubert for contribution of the 1826 original registration idea and extensive contributions to earlier 1827 versions of the draft, Jonathan Hui for original ideas on prefix/ 1828 context distribution and extensive contributions to earlier versions 1829 of the draft, and Geoff Mulligan for suggesting the use of Address 1830 Registration as part of existing IPv6 Neighbor Discovery messages. 1832 14. Changelog 1834 Changes from -09 to -10: 1836 o Clarifications made to Section 8.2 (#66) 1838 o Explained behavior of Neighbor Cache (#67) 1840 o Clarified use of SLLAO in RS and NS messages (#68) 1842 o Added new term 6LN (#69) 1844 o Small clarification on 6CO flag (#70) 1846 o Defined host behavior on ARO failure better (#72) 1848 o Added bootstrapping example for a host (#73) 1850 o Added new Neighbor Cache Full ARO error (#74) 1852 o Added rule on the use of the M flag (#75) 1854 Changes from -08 to -09: 1856 o Clean re-write of the draft (re-use of some introductory 1857 material) 1859 o Merged in draft-chakrabarti-6lowpan-ipv6-nd-simple-00 1861 o Changed address registration to an option piggybacked on NS/NA 1863 o New Authoritative Border Router option 1865 o New Address Registration Option 1867 o Separated Prefix Information and Content Information 1869 o Optional DAD to the edge 1871 Changes from -07 to -08: 1873 o Removed Extended LoWPAN and Whiteboard related sections. 1875 o Included reference to the autoconf addressing model. 1877 o Added Optimistic Flag to 6AO. 1879 o Added guidelines on routers performing DAD. 1881 o Removed the NR/NC Advertising Interval. 1883 o Added assumption of uniform IID formation and DAD throughout a 1884 LoWPAN. 1886 Changes from -06 to -07: 1888 o Updated addressing and address resolution (#60). 1890 o Changed the Address Option to 6LoWPAN Address Option, fixed S 1891 values (#61). 1893 o Added support for classic RFC4861 RA Prefix Information messages 1894 to be processed (#62). 1896 o Added a section on using 6LoWPAN-ND under a hard-wired RFC4861 1897 stack (#63). 1899 o Updated the NR/NC message with a new Router flag, combined the 1900 Code and Status fields into one byte, and added the capability to 1901 carry 6IOs (#64). 1903 o Made co-existence with other ND mechanisms clear (#59). 1905 o Added a new Protocol Specification section with all mechanisms 1906 specified there (#59). 1908 o Removed dependencies and conflicts with RFC4861 wherever 1909 possible (#59). 1911 o Some editorial cleanup. 1913 Changes from -05 to -06: 1915 o Fixed the Prf codes (#52). 1917 o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII 1918 order in both the OIIO and the NR/NC. (#53) 1920 o Corrected an error in Table 1 (#54). 1922 o Fixed asymmetric and a misplaced transient in the 6LoWPAN 1923 terminology section. 1925 o Added Updates RFC4861 to header 1927 Changes from -04 to -05: 1929 o Meaning of the RA's M-bit changed to original [RFC4861] meaning 1930 (#46). 1932 o Terms "on-link" and "off-link" used in place of "on-link" and 1933 "off-link". 1935 o Next-hop determination text simplified (#49). 1937 o Neighbor cache and destination cache removed. 1939 o IID to link-layer address requirement relaxed. 1941 o NR/NC changes to enable on-link refresh with routers (#48). 1943 o Modified 6LoWPAN Information Option (#47). 1945 o Added a Protocol Constants section (#24) 1947 o Added the NR processing table (#51) 1949 o Considered the use of SeND on backbone NS/NA messages (#50) 1951 Changes from -03 to -04: 1953 o Moved Ad-hoc LoWPAN operation to Section 7 and made ULA prefix 1954 generation a features useful also in Simple and Extended LoWPANs. 1955 (#41) 1957 o Added a 32-bit Owner Nonce to the NR/NC messages and the 1958 Whiteboard, removed the TID history. (#39) 1960 o Improved the duplicate OII detection algorithm using the Owner 1961 Nonce. (#39) 1963 o Clarified the use of Source and Target link-layer options in 1964 NR/NC. (#43) 1966 o Included text on the use of alternative methods to acquire 1967 addresses. (#38) 1969 o Removed S=2 from Address Option (not needed). (#36) 1971 o Added a section on router dissemination consistency. (#44) 1973 o Small improvements and extensive editing. (#42, #37, #35) 1975 Changes from -02 to -03: 1977 o Updated terminology, with RFC4861 non-transitive link model. 1979 o 6LoWPAN and ND terminology separated. 1981 o Protocol overview explains RFC4861 diff in detail. 1983 o RR/RC is now Node Registration/Confirmation (NR/NC). 1985 o Added NR failure codes. 1987 o ER Metric now included in 6LoWPAN Summary Option for use in 1988 default router determination by hosts. 1990 o Examples of host data structures, and the Whiteboard given. 1992 o Whiteboard is supported by all Edge Routers for option 1993 simplicity. 1995 o Edge Router Specification chapter re-structured, clarifying 1996 optional Extended LoWPAN operation. 1998 o NS/NA now completely optional for nodes. No address resolution 1999 or NS/NA NUD required. 2001 o link-local operation now compatible with oDAD (was broken). 2003 o Exception to hop limit = 255 for NR/NC messages. 2005 o Security considerations improved. 2007 o ICMPv6 destination unreachable supported. 2009 Changes from -01 to -02: 2011 o Fixed 16 != 0xff bug (ticket closed). 2013 o Specified use of ULAs in ad-hoc LoWPAN section 9 (ticket 2014 closed). 2016 o Terminology cleanup based on Alex's comments. 2018 o General editing improvements. 2020 Changes from -00 to -01: 2022 o Specified the duplicate owner interface identifier procedures. 2023 A TID lollipop algorithm was sufficient (nonce unnecessary). 2025 o Defined fault tolerance using secondary bindings. 2027 o Defined ad-hoc network operation. 2029 o Removed the E flag from RA and the X flag from RR/RC. 2031 o Completed message examples. 2033 o Lots of improvements in text quality and consistency were made. 2035 15. References 2037 15.1. Normative References 2039 [I-D.ietf-autoconf-adhoc-addr-model] 2040 Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 2041 Hoc Networks", draft-ietf-autoconf-adhoc-addr-model-03 2042 (work in progress), March 2010. 2044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2045 Requirement Levels", BCP 14, RFC 2119, March 1997. 2047 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2048 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2049 October 1998. 2051 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2052 (IPv6) Specification", RFC 2460, December 1998. 2054 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 2055 over Non-Broadcast Multiple Access (NBMA) networks", 2056 RFC 2491, January 1999. 2058 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2059 More-Specific Routes", RFC 4191, November 2005. 2061 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2062 Addresses", RFC 4193, October 2005. 2064 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2065 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2066 September 2007. 2068 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2069 Address Autoconfiguration", RFC 4862, September 2007. 2071 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2072 "Transmission of IPv6 Packets over IEEE 802.15.4 2073 Networks", RFC 4944, September 2007. 2075 15.2. Informative References 2077 [I-D.ietf-6lowpan-hc] 2078 Hui, J. and P. Thubert, "Compression Format for IPv6 2079 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-07 2080 (work in progress), April 2010. 2082 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2083 and M. Carney, "Dynamic Host Configuration Protocol for 2084 IPv6 (DHCPv6)", RFC 3315, July 2003. 2086 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2087 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2088 December 2003. 2090 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 2091 Discovery (ND) Trust Models and Threats", RFC 3756, 2092 May 2004. 2094 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2095 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2097 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2098 RFC 3972, March 2005. 2100 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2101 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2102 Overview, Assumptions, Problem Statement, and Goals", 2103 RFC 4919, August 2007. 2105 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2106 Extensions for Stateless Address Autoconfiguration in 2107 IPv6", RFC 4941, September 2007. 2109 Authors' Addresses 2111 Zach Shelby (editor) 2112 Sensinode 2113 Hallituskatu 13-17D 2114 Oulu 90100 2115 FINLAND 2117 Phone: +358407796297 2118 Email: zach@sensinode.com 2120 Samita Chakrabarti 2121 IP Infusion 2122 1188 Arquest Street 2123 Sunnyvale, CA 2124 USA 2126 Email: samitac@ipinfusion.com 2128 Erik Nordmark 2129 Oracle, Inc. 2130 17 Network Circle 2131 Menlo Park, CA 94025 2132 USA 2134 Email: Erik.Nordmark@Oracle.COM