idnits 2.17.1 draft-thubert-6lo-rfc6775-update-reqs-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2016) is 2944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6217' is defined on line 515, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-04 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-04 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-09 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo P. Thubert, Ed. 3 Internet-Draft cisco 4 Intended status: Informational P. van der Stok 5 Expires: October 6, 2016 consultant 6 April 4, 2016 8 Requirements for an update to 6LoWPAN ND 9 draft-thubert-6lo-rfc6775-update-reqs-07 11 Abstract 13 Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups 14 suggest that enhancements to the 6LoWPAN ND mechanism are now needed. 15 This document elaborates on those requirements and suggests 16 approaches to serve them. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 6, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Requirements Related to Mobility . . . . . . . . . . . . 6 57 4.2. Requirements Related to Routing Protocols . . . . . . . . 7 58 4.3. Requirements Related to the Variety of Low-Power Link 59 types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.4. Requirements Related to Proxy Operations . . . . . . . . 8 61 4.5. Requirements Related to Security . . . . . . . . . . . . 9 62 4.6. Requirements Related to Scalability . . . . . . . . . . . 10 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 8.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Appendix A. Suggested Changes to Protocol Elements . . . . . . . 14 70 A.1. ND Neighbor Solicitation (NS) . . . . . . . . . . . . . . 14 71 A.2. ND Router Advertisement (RA) . . . . . . . . . . . . . . 14 72 A.3. RPL DODAG Information Object (DIO) . . . . . . . . . . . 15 73 A.4. ND Enhanced Address Registration Option (EARO) . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 A number of use cases, including the Industrial Internet, require a 79 large scale deployment of sensors that can not be realized with wires 80 and is only feasible over wireless Low power and Lossy Network (LLN) 81 technologies. When simpler hub-and-spoke topologies are not 82 sufficient for the expected throughput and density, mesh networks are 83 deployed, which implies the routing of packets over the mesh, 84 operated at either Layer-2 or Layer-3. 86 For routing over a mesh at layer-3, the IETF has designed the IPv6 87 Routing Protocol over LLN (RPL) [RFC6550]. 89 To assign routable addresses, DHCPv6 is still a viable option in 90 LLNs. However, the IETF standard that supports address assignment 91 specifically for LLNs is 6LoWPAN ND, the Neighbor Discovery 92 Optimization for Low-power and Lossy Networks [RFC6775]. 6LoWPAN ND 93 was designed as a stand-alone mechanism separately from its IETF 94 routing counterpart, the IPv6 Routing Protocol for Low power and 95 Lossy Networks [RFC6550] (RPL), and the interaction between the 2 96 protocols was not defined. 98 The 6TiSCH WG is now considering an architecture 99 [I-D.ietf-6tisch-architecture] whereby a 6LowPAN ND host could 100 connect to the Internet via a RPL Network, but this requires 101 additions to the 6LOWPAN ND protocol to support mobility and 102 reachability in a secured and manageable environment. 104 At the same time, new work at 6MAN on Efficiency aware IPv6 Neighbor 105 Discovery Optimizations [I-D.chakrabarti-nordmark-6man-efficient-nd] 106 suggests that 6LoWPAN ND can be extended to other types of networks 107 on top of the Low power and Lossy Networks (LLNs) for which it was 108 already defined. The value of such extension is especially apparent 109 in the case of mobile wireless devices, to reduce the multicast 110 operations that are related to classical ND ([RFC4861], [RFC4862]) 111 and plague the wireless medium. In this context also, there is a 112 need for additions to 6LOWPAN ND. 114 The Optimistic Duplicate Address Detection [RFC4429] (ODAD) 115 specification details how an address can be used before a Duplicate 116 Address Detection (DAD) is complete, and insists that an address that 117 is TENTATIVE should not be associated to a Source Link-Layer Address 118 Option in a Neighbor Solicitation message. Applying this rule to 119 6LOWPAN ND implies another change to its specification. 121 In [I-D.richardson-6tisch--security-6top], the 6tisch working group 122 considers the use of layer-2 security. It develops a network 123 bootstrap protocol that provides secure link connections at the same 124 rate that nodes are discovered. This approach needs the presence of 125 a routing protocol to route packets from a joining node to a security 126 providing node (e.g. a PCE or commissioning tool). 128 This document suggests a limited evolution to [RFC6775] so as to 129 allow operation of a 6LoWPAN ND node while a routing protocol (in 130 first instance RPL) is present and operational. It also suggests a 131 more generalized use of the information in the ARO option of the ND 132 messages outside the strict LLN domain, for instance over a converged 133 backbone. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 Readers are expected to be familiar with all the terms and concepts 142 that are discussed in "Neighbor Discovery for IP version 6" 143 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 144 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 145 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 146 Neighbor Discovery Optimization for Low-power and Lossy Networks 147 [RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4 148 Networks" [RFC4944]. 150 Additionally, this document uses terminology from 6TiSCH 151 [I-D.ietf-6tisch-terminology] and ROLL [RFC7102]. 153 3. Overview 155 This document is mostly motivated by the work ongoing in the 6TiSCH 156 working group. The 6TiSCH architecture 157 [I-D.ietf-6tisch-architecture] draft explains the network 158 architecture of a 6TiSCH network. This architecture is used for the 159 remainder of this document. 161 The scope of the 6TiSCH Architecture is a Backbone Link that 162 federates multiple LLNs (mesh) as a single IPv6 Multi-Link Subnet. 163 Each LLN in the subnet is anchored at a Backbone Router (6BBR). The 164 Backbone Routers interconnect the LLNs over the Backbone Link and 165 emulate that the LLN nodes are present on the Backbone thus creating 166 a so-called: Multi-Link Subnet. An LLN node can move freely from an 167 LLN anchored at a Backbone Router to another LLN anchored at the same 168 or a different Backbone Router inside the Multi-Link Subnet and 169 conserve its addresses. 171 ---+------------------------ 172 | Plant Network 173 | 174 +-----+ 175 | | Gateway 176 | | 177 +-----+ 178 | 179 | Backbone Link (with VLANs) 180 +--------------------+------------------+ 181 | | | 182 +-----+ +-----+ +-----+ 183 | | Backbone | | Backbone | | Backbone 184 | | router | | router | | router 185 +-----+ +-----+ +-----+ 186 | | | | | | 187 0 0 0 0 0 (6LBR == LLN border router) 188 o o o o o o o o o o o o o o 189 o o o o o o o o o o (6LR == LLN router) 190 o o o o o o o z 191 o o o o o z 192 RPL Instances (6LoWPAN Host == LLN host) 194 Figure 1: 6TiSCH architecture 196 The 6LBR is the border router that is placed between the LLN and 197 nodes outside the LLN. The 6LBR is logically separated from the 6BBR 198 that is used to connect the LLN to the backbone. The 6LBR can use 199 Efficient ND as the interface to register an LLN node in its topology 200 to the 6BBR for whatever operation the 6BBR performs, such as ND 201 proxy operations, or injection in a routing protocol. It results 202 that, as illustrated in Figure 2, the periodic signaling could start 203 at the leaf node with 6LoWPAN ND, then would be routed to the 6LBR, 204 and then with Efficient-ND to the 6BBR. Efficient ND being an 205 adaptation of 6LoWPAN ND, it makes sense to keep those two 206 homogeneous in the way they use the source and the target addresses 207 in the Neighbor Solicitation (NS) messages for registration, as well 208 as in the options that they use for that process. 210 6LoWPAN host 6LR 6LBR 6BBR 212 | | | | 213 | 6LoWPAN ND | 6LoWPAN ND | Efficient ND | IPv6 ND 214 | LLN link | IPv6 route | IPv6 link | Backbone 215 | | | | 216 | NS(ARO) | | | 217 |-------------->| | | 218 | 6LoWPAN ND | DAR (then DAO)| | 219 | |-------------->| | 220 | | | NS(ARO) | 221 | | |-------------->| 222 | | | | DAD 223 | | | |------> 224 | | | | 225 | | | NA(ARO) | 226 | | |<--------------| 227 | | DAC | | 228 | |<--------------| | 229 | NA(ARO) | | | 230 |<--------------| | | 232 Figure 2: (Re-)Registration Flow over Multi-Link Subnet 234 As the network builds up, a LoWPAN host starts as a leaf to join the 235 LLN, and may later turn into a 6LR, so as to accept other nodes to 236 recursively join the LLN. 238 Section 5 of the 6TiSCH architecture [I-D.ietf-6tisch-architecture] 239 provides more information on the need to update the protocols that 240 sustain the requirements in the next section. 242 4. Requirements 244 4.1. Requirements Related to Mobility 246 Due to the unstable nature of LLN links, even in a LLN of immobile 247 nodes a 6LoWPAN Node may change its point of attachment to a 6LR, say 248 6LR-a, and may not be able to notify 6LR-a. Consequently, 6LR-a may 249 still attract traffic that it cannot deliver any more. When links to 250 a 6LR change state, there is thus a need to identify stale states in 251 a 6LR and restore reachability in a timely fashion. 253 Req1.1: Upon a change of point of attachment, connectivity via a new 254 6LR MUST be restored timely without the need to de-register from the 255 previous 6LR. 257 Req1.2: For that purpose, the protocol MUST enable to differentiate 258 between multiple registrations from one 6LoWPAN Node and 259 registrations from different 6LoWPAN Nodes claiming the same address. 261 Req1.3: Stale states MUST be cleaned up in 6LRs. 263 Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address 264 to multiple 6LRs, and this, concurrently. 266 4.2. Requirements Related to Routing Protocols 268 The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN 269 mesh. IPv6 routing in a LLN can be based on RPL, which is the 270 routing protocol that was defined at the IETF for this particular 271 purpose. Other routing protocols than RPL are also considered by 272 Standard Defining Organizations (SDO) on the basis of the expected 273 network characteristics. It is required that a 6LoWPAN Node attached 274 via ND to a 6LR would need to participate in the selected routing 275 protocol to obtain reachability via the 6LR. 277 Next to the 6LBR unicast address registered by ND, other addresses 278 including multicast addresses are needed as well. For example a 279 routing protocol often uses a multicast address to register changes 280 to established paths. ND needs to register such a multicast address 281 to enable routing concurrently with discovery. 283 Multicast is needed for groups. Groups MAY be formed by device type 284 (e.g. routers, street lamps), location (Geography, RPL sub-tree), or 285 both. 287 The Bit Index Explicit Replication (BIER) Architecture 288 [I-D.wijnands-bier-architecture] proposes an optimized technique to 289 enable multicast in a LLN with a very limited requirement for routing 290 state in the nodes. 292 Related requirements are: 294 Req2.1: The ND registration method SHOULD be extended in such a 295 fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over 296 the selected routing protocol and obtain reachability to that Address 297 using the selected routing protocol. 299 Req2.2: Considering RPL, the Address Registration Option that is used 300 in the ND registration SHOULD be extended to carry enough information 301 to generate a DAO message as specified in [RFC6550] section 6.4, in 302 particular the capability to compute a DAOSequence and, as an option, 303 a RPLInstanceID. 305 Req2.3: Multicast operations SHOULD be supported and optimized, for 306 instance using BIER or MPL. Whether ND is appropriate for the 307 registration to the 6BBR is to be defined, considering the additional 308 burden of supporting the Multicast Listener Discovery Version 2 309 [RFC3810] (MLDv2) for IPv6. 311 4.3. Requirements Related to the Variety of Low-Power Link types 313 6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in 314 particular the capability to derive a unique Identifier from a 315 globally unique MAC-64 address. At this point, the 6lo Working Group 316 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 317 to other link types ITU-T G.9959 [I-D.brandt-6man-lowpanz], Master- 318 Slave/Token-Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy 319 [I-D.ietf-6lo-dect-ule], Near Field Communication 320 [I-D.hong-6lo-ipv6-over-nfc], as well as IEEE1901.2 Narrowband 321 Powerline Communication Networks 322 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) 323 Low Energy [I-D.ietf-6lo-btle]. 325 Related requirements are: 327 Req3.1: The support of the registration mechanism SHOULD be extended 328 to more LLN links than IEEE 802.15.4, matching at least the LLN links 329 for which an "IPv6 over foo" specification exists, as well as Low- 330 Power Wi-Fi. 332 Req3.2: As part of this extension, a mechanism to compute a unique 333 Identifier should be provided, with the capability to form a Link- 334 Local Address that SHOULD be unique at least within the LLN connected 335 to a 6LBR discovered by ND in each node within the LLN. 337 Req3.3: The Address Registration Option used in the ND registration 338 SHOULD be extended to carry the relevant forms of unique Identifier. 340 Req3.4: The Neighbour Discovery should specify the formation of a 341 site-local address that follows the security recommendations from 342 [RFC7217]. 344 4.4. Requirements Related to Proxy Operations 346 Duty-cycled devices may not be able to answer themselves to a lookup 347 from a node that uses classical ND on a backbone and may need a 348 proxy. Additionally, the duty-cycled device may need to rely on the 349 6LBR to perform registration to the 6BBR. 351 The ND registration method SHOULD defend the addresses of duty-cycled 352 devices that are sleeping most of the time and not capable to defend 353 their own Addresses. 355 Related requirements are: 357 Req4.1: The registration mechanism SHOULD enable a third party to 358 proxy register an Address on behalf of a 6LoWPAN node that may be 359 sleeping or located deeper in an LLN mesh. 361 Req4.2: The registration mechanism SHOULD be applicable to a duty- 362 cycled device regardless of the link type, and enable a 6BBR to 363 operate as a proxy to defend the registered Addresses on its behalf. 365 Req4.3: The registration mechanism SHOULD enable long sleep 366 durations, in the order of multiple days to a month. 368 4.5. Requirements Related to Security 370 In order to guarantee the operations of the 6LoWPAN ND flows, the 371 spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a 372 node successfully registers an address, 6LoWPAN ND should provide 373 energy-efficient means for the 6LBR to protect that ownership even 374 when the node that registered the address is sleeping. 376 In particular, the 6LR and the 6LBR then should be able to verify 377 whether a subsequent registration for a given Address comes from the 378 original node. 380 In a LLN it makes sense to base security on layer-2 security. During 381 bootstrap of the LLN, nodes join the network after authorization by a 382 Joining Assistant (JA) or a Commissioning Tool (CT). After joining 383 nodes communicate with each other via secured links. The keys for 384 the layer-2 security are distributed by the JA/CT. The JA/CT can be 385 part of the LLN or be outside the LLN. In both cases it is needed 386 that packets are routed between JA/CT and the joining node. 388 Related requirements are: 390 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 391 the 6LR, 6LBR and 6BBR to authenticate and authorize one another for 392 their respective roles, as well as with the 6LoWPAN Node for the role 393 of 6LR. 395 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 396 the 6LR and the 6LBR to validate new registration of authorized 397 nodes. Joining of unauthorized nodes MUST be impossible. 399 Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet 400 sizes. In particular, the NS, NA, DAR and DAC messages for a re- 401 registration flow SHOULD NOT exceed 80 octets so as to fit in a 402 secured IEEE802.15.4 frame. 404 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 405 computationally intensive on the LoWPAN Node CPU. When a Key hash 406 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 407 preferred. 409 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 410 SHOULD be minimized. 412 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use 413 at both Layer 2 and Layer 3, and SHOULD enable the reuse of security 414 code that has to be present on the device for upper layer security 415 such as TLS. 417 Req5.7: Public key and signature sizes SHOULD be minimized while 418 maintaining adequate confidentiality and data origin authentication 419 for multiple types of applications with various degrees of 420 criticality. 422 Req5.8: Routing of packets should continue when links pass from the 423 unsecured to the secured state. 425 Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 426 the 6LR and the 6LBR to validate whether a new registration for a 427 given address corresponds to the same 6LoWPAN Node that registered it 428 initially, and, if not, determine the rightful owner, and deny or 429 clean-up the registration that is duplicate. 431 4.6. Requirements Related to Scalability 433 Use cases from Automatic Meter Reading (AMR, collection tree 434 operations) and Advanced Metering Infrastructure (AMI, bi-directional 435 communication to the meters) indicate the needs for a large number of 436 LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected 437 to the 6LBR over a large number of LLN hops (e.g. 15). 439 Related requirements are: 441 Req6.1: The registration mechanism SHOULD enable a single 6LBR to 442 register multiple thousands of devices. 444 Req6.2: The timing of the registration operation should allow for a 445 large latency such as found in LLNs with ten and more hops. 447 5. Security Considerations 449 This specification expects that the link layer is sufficiently 450 protected, either by means of IP security for the Backbone Link or 451 MAC sublayer cryptography. In particular, it is expected that the 452 LLN MAC provides secure unicast to/from the Backbone Router and 453 secure broadcast from the Backbone Router in a way that prevents 454 tampering with or replaying the RA messages. Still, Section 4.5 has 455 a requirement for a mutual authentication and authorization for a 456 role for 6LRs, 6LBRs and 6BBRs. 458 This documents also suggests in Appendix A.4 that a 6LoWPAN Node 459 could form a single Unique Interface ID (CUID) based on cryptographic 460 techniques similar to CGA. The CUID would be used as Unique 461 Interface Identifier in the ARO option and new Secure ND procedures 462 would be proposed to use it as opposed to the source IPv6 address to 463 secure the binding between an Address and its owning Node, and 464 enforce First/Come-First/Serve at the 6LBR. 466 6. IANA Considerations 468 This draft does not require an IANA action. 470 7. Acknowledgments 472 The author wishes acknowledge the contributions by Samita 473 Chakrabarti, Erik Normark, JP Vasseur, Eric Levy-Abegnoli, Patrick 474 Wetterwald, Thomas Watteyne, and Behcet Sarikaya. 476 8. References 478 8.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 486 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 487 DOI 10.17487/RFC3810, June 2004, 488 . 490 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 491 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 492 . 494 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 495 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 496 DOI 10.17487/RFC4861, September 2007, 497 . 499 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 500 Address Autoconfiguration", RFC 4862, 501 DOI 10.17487/RFC4862, September 2007, 502 . 504 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 505 over Low-Power Wireless Personal Area Networks (6LoWPANs): 506 Overview, Assumptions, Problem Statement, and Goals", 507 RFC 4919, DOI 10.17487/RFC4919, August 2007, 508 . 510 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 511 "Transmission of IPv6 Packets over IEEE 802.15.4 512 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 513 . 515 [RFC6217] Ritter, T., "Regional Broadcast Using an Atmospheric Link 516 Layer", RFC 6217, DOI 10.17487/RFC6217, April 2011, 517 . 519 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 520 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 521 DOI 10.17487/RFC6282, September 2011, 522 . 524 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 525 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 526 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 527 Low-Power and Lossy Networks", RFC 6550, 528 DOI 10.17487/RFC6550, March 2012, 529 . 531 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 532 Bormann, "Neighbor Discovery Optimization for IPv6 over 533 Low-Power Wireless Personal Area Networks (6LoWPANs)", 534 RFC 6775, DOI 10.17487/RFC6775, November 2012, 535 . 537 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 538 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 539 2014, . 541 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 542 Interface Identifiers with IPv6 Stateless Address 543 Autoconfiguration (SLAAC)", RFC 7217, 544 DOI 10.17487/RFC7217, April 2014, 545 . 547 8.2. Informative References 549 [I-D.brandt-6man-lowpanz] 550 Brandt, A. and J. Buron, "Transmission of IPv6 packets 551 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 552 (work in progress), June 2013. 554 [I-D.chakrabarti-nordmark-6man-efficient-nd] 555 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 556 Wasserman, "IPv6 Neighbor Discovery Optimizations for 557 Wired and Wireless Networks", draft-chakrabarti-nordmark- 558 6man-efficient-nd-07 (work in progress), February 2015. 560 [I-D.hong-6lo-ipv6-over-nfc] 561 Hong, Y. and J. Youn, "Transmission of IPv6 Packets over 562 Near Field Communication", draft-hong-6lo-ipv6-over-nfc-03 563 (work in progress), November 2014. 565 [I-D.ietf-6lo-6lobac] 566 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 567 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 568 6lo-6lobac-04 (work in progress), February 2016. 570 [I-D.ietf-6lo-btle] 571 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 572 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 573 Energy", draft-ietf-6lo-btle-17 (work in progress), August 574 2015. 576 [I-D.ietf-6lo-dect-ule] 577 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 578 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 579 Energy", draft-ietf-6lo-dect-ule-04 (work in progress), 580 February 2016. 582 [I-D.ietf-6tisch-architecture] 583 Thubert, P., "An Architecture for IPv6 over the TSCH mode 584 of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work 585 in progress), November 2015. 587 [I-D.ietf-6tisch-terminology] 588 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 589 "Terminology in IPv6 over the TSCH mode of IEEE 590 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 591 progress), March 2016. 593 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 594 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 595 over IEEE 1901.2 Narrowband Powerline Communication 596 Networks", draft-popa-6lo-6loplc-ipv6-over- 597 ieee19012-networks-00 (work in progress), March 2014. 599 [I-D.richardson-6tisch--security-6top] 600 Richardson, M., "6tisch secure join using 6top", draft- 601 richardson-6tisch--security-6top-05 (work in progress), 602 November 2015. 604 [I-D.wijnands-bier-architecture] 605 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 606 S. Aldrin, "Multicast using Bit Index Explicit 607 Replication", draft-wijnands-bier-architecture-05 (work in 608 progress), March 2015. 610 Appendix A. Suggested Changes to Protocol Elements 612 A.1. ND Neighbor Solicitation (NS) 614 The NS message used for registration should use a source address that 615 respects the rules in [RFC6775], [RFC4861], and [RFC4429] for DAD. 616 The SLLA Option may be present but only if the address passed DAD, 617 and it is used to allow the 6LR to respond as opposed to as a 618 registration mechanism. 620 The address that is being registered is the target address in the NS 621 message and the TLLA Option must be present. 623 A.2. ND Router Advertisement (RA) 625 [I-D.chakrabarti-nordmark-6man-efficient-nd] adds an 'E' bit in the 626 Router Advertisement flag, as well as a new Registrar Address Option 627 (RAO). These fields are probably pertinent to LLNs inclusion into a 628 revised 6LoWPAN ND should be studied. If the new 6LoWPAN flows 629 require a change of behaviour (e.g. registering the Target of the NS 630 message) then the RA must indicate that the router supports the new 631 capability, and the NS must indicate that the Target is registered as 632 opposed to the Source in an unequivocal fashion. 634 There is some amount of duplication between the options in the RPL 635 DIO [RFC6550] and the options in the ND RA messages. At the same 636 time, there are a number of options, including the 6LoWPAN Context 637 Option (6CO) [RFC6775], the MTU and the SLLA Options [RFC4861] that 638 can only be found in the RA messages. Considering that these options 639 are useful for a joining node, the recommendation would be to 640 associate the RA messages to the join beacon, and make them rare when 641 the network is stable. On the other hand, the DIO message is to be 642 used as the propagated heartbeat of the RPL network and provide the 643 sense of time and liveliness. 645 RAs should also be issued and the information therein propagated when 646 a change occurs in the information therein, such as a router or a 647 prefix lifetime. 649 A.3. RPL DODAG Information Object (DIO) 651 If the RPL root serves as 6LBR, it makes sense to add at least a bit 652 of information in the DIO to signal so. A Registrar Address Option 653 (RAO) may also be considered for addition. 655 A.4. ND Enhanced Address Registration Option (EARO) 657 The ARO option contains a Unique ID that is supposed to identify the 658 device across multiple registrations. It is envisioned that the 659 device could form a single CGA-based Unique Interface ID (CUID) to 660 securely bind all of its addresses. The CUID would be used as Unique 661 Interface Identifier in the ARO option and to form a Link-Local 662 address that would be deemed unique regardless of the Link type. 663 Provided that the relevant cryptographic material is passed to the 664 6LBR upon the first registration or on-demand at a later time, the 665 6LBR can validate that a Node is effectively the owner of a CUID, and 666 ensure that the ownership of an Address stays with the CUID that 667 registered it first. 669 This option is designed to be used with standard NS and NA messages 670 between backbone Routers as well as between nodes and 6LRs over the 671 LLN and between the 6LBR and the 6BBR over whatever IP link they use 672 to communicate. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Type | Length | Status | RPLInstanceID | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |Res|P|N| IDS |T| TID | Registration Lifetime | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 ~ Unique Interface Identifier (variable length) ~ 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 3: EARO 688 The representation above is based on 689 [I-D.chakrabarti-nordmark-6man-efficient-nd]. Only the proposed 690 changes from that specification are discussed below but the 691 expectation is that 6LoWPAN ND and Efficient ND converge on the ARO 692 format. 694 Status: 8-bit integer. A new value of 3 is suggested to indicate a 695 rejection due to an obsolete TID, typically an indication of a 696 movement. 698 RPLInstanceID: 8-bit integer. This field is set to 0 when unused. 699 Otherwise it contains the RPLInstanceID for which this address is 700 registered, as specified in RPL [RFC6550], and discussed in 701 particular in section 3.1.2. 703 P: One bit flag. When the bit is set, the address being registered 704 is Target of the NS as opposed to the Source, for instance to 705 enable ND proxy operation. 707 N: One bit flag. Set if the device moved. If not set, the 6BBR will 708 refrain from sending gratuitous NA(O) or other form of distributed 709 ND cache clean-up over the backbone. For instance, the flag 710 should be reset after the DAD operation upon address formation. 712 Authors' Addresses 713 Pascal Thubert (editor) 714 Cisco Systems, Inc 715 Building D 716 45 Allee des Ormes - BP1200 717 MOUGINS - Sophia Antipolis 06254 718 FRANCE 720 Phone: +33 497 23 26 34 721 Email: pthubert@cisco.com 723 Peter van der Stok 724 consultant 726 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 727 Email: consultancy@vanderstok.org 728 URI: www.vanderstok.org