idnits 2.17.00 (12 Aug 2021) /tmp/idnits24845/draft-thubert-6lo-rfc6775-update-reqs-06.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 (January 14, 2015) is 2684 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC6655' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 615, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-chakrabarti-nordmark-6man-efficient-nd-06 == Outdated reference: draft-ietf-6lo-6lobac has been published as RFC 8163 == Outdated reference: draft-ietf-6lo-btle has been published as RFC 7668 == Outdated reference: draft-ietf-6lo-dect-ule has been published as RFC 8105 == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-03 == Outdated reference: A later version (-05) exists of draft-richardson-6tisch--security-6top-04 == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-02 Summary: 1 error (**), 0 flaws (~~), 20 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: Standards Track P. van der Stok 5 Expires: July 18, 2015 consultant 6 January 14, 2015 8 Requirements for an update to 6LoWPAN ND 9 draft-thubert-6lo-rfc6775-update-reqs-06 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 July 18, 2015. 35 Copyright Notice 37 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . 12 69 Appendix A. Suggested Changes to Protocol Elements . . . . . . . 14 70 A.1. ND Neighbor Solicitation (NS) . . . . . . . . . . . . . . 14 71 A.2. ND Router Advertisement (RA) . . . . . . . . . . . . . . 15 72 A.3. RPL DODAG Information Object (DIO) . . . . . . . . . . . 15 73 A.4. ND Enhanced Address Registration Option (EARO) . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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, March 1997. 483 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 484 (IPv6) Specification", RFC 2460, December 1998. 486 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 487 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 489 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 490 Architecture", RFC 4291, February 2006. 492 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 493 for IPv6", RFC 4429, April 2006. 495 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 496 Message Protocol (ICMPv6) for the Internet Protocol 497 Version 6 (IPv6) Specification", RFC 4443, March 2006. 499 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 500 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 501 September 2007. 503 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 504 Address Autoconfiguration", RFC 4862, September 2007. 506 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 507 "Transmission of IPv6 Packets over IEEE 802.15.4 508 Networks", RFC 4944, September 2007. 510 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 511 in IPv6", RFC 6275, July 2011. 513 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 514 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 515 September 2011. 517 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 518 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 519 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 520 Lossy Networks", RFC 6550, March 2012. 522 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 523 Transport Layer Security (TLS)", RFC 6655, July 2012. 525 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 526 "Neighbor Discovery Optimization for IPv6 over Low-Power 527 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 528 November 2012. 530 8.2. Informative References 532 [I-D.brandt-6man-lowpanz] 533 Brandt, A. and J. Buron, "Transmission of IPv6 packets 534 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 535 (work in progress), June 2013. 537 [I-D.chakrabarti-nordmark-6man-efficient-nd] 538 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 539 Wasserman, "IPv6 Neighbor Discovery Optimizations for 540 Wired and Wireless Networks", draft-chakrabarti-nordmark- 541 6man-efficient-nd-06 (work in progress), July 2014. 543 [I-D.hong-6lo-ipv6-over-nfc] 544 Hong, Y. and J. Youn, "Transmission of IPv6 Packets over 545 Near Field Communication", draft-hong-6lo-ipv6-over-nfc-03 546 (work in progress), November 2014. 548 [I-D.ietf-6lo-6lobac] 549 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 550 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 551 6lo-6lobac-00 (work in progress), July 2014. 553 [I-D.ietf-6lo-btle] 554 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 555 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 556 over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-06 557 (work in progress), January 2015. 559 [I-D.ietf-6lo-dect-ule] 560 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 561 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 562 Energy", draft-ietf-6lo-dect-ule-00 (work in progress), 563 June 2014. 565 [I-D.ietf-6tisch-architecture] 566 Thubert, P., Watteyne, T., and R. Assimiti, "An 567 Architecture for IPv6 over the TSCH mode of IEEE 568 802.15.4e", draft-ietf-6tisch-architecture-04 (work in 569 progress), October 2014. 571 [I-D.ietf-6tisch-terminology] 572 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 573 "Terminology in IPv6 over the TSCH mode of IEEE 574 802.15.4e", draft-ietf-6tisch-terminology-03 (work in 575 progress), January 2015. 577 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 578 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 579 over IEEE 1901.2 Narrowband Powerline Communication 580 Networks", draft-popa-6lo-6loplc-ipv6-over- 581 ieee19012-networks-00 (work in progress), March 2014. 583 [I-D.richardson-6tisch--security-6top] 584 Richardson, M., "6tisch secure join using 6top", draft- 585 richardson-6tisch--security-6top-04 (work in progress), 586 November 2014. 588 [I-D.wijnands-bier-architecture] 589 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 590 S. Aldrin, "Multicast using Bit Index Explicit 591 Replication", draft-wijnands-bier-architecture-02 (work in 592 progress), December 2014. 594 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 595 CBC-MAC (CCM)", RFC 3610, September 2003. 597 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 598 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 599 RFC 3963, January 2005. 601 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 602 Neighbor Discovery (SEND)", RFC 3971, March 2005. 604 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 605 RFC 3972, March 2005. 607 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 608 Proxies (ND Proxy)", RFC 4389, April 2006. 610 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 611 over Low-Power Wireless Personal Area Networks (6LoWPANs): 612 Overview, Assumptions, Problem Statement, and Goals", RFC 613 4919, August 2007. 615 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 616 Locator/ID Separation Protocol (LISP)", RFC 6830, January 617 2013. 619 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 620 Lossy Networks", RFC 7102, January 2014. 622 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 623 Interface Identifiers with IPv6 Stateless Address 624 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 626 Appendix A. Suggested Changes to Protocol Elements 628 A.1. ND Neighbor Solicitation (NS) 630 The NS message used for registration should use a source address that 631 respects the rules in [RFC6775], [RFC4861], and [RFC4429] for DAD. 632 The SLLA Option may be present but only if the address passed DAD, 633 and it is used to allow the 6LR to respond as opposed to as a 634 registration mechanism. 636 The address that is being registered is the target address in the NS 637 message and the TLLA Option must be present. 639 A.2. ND Router Advertisement (RA) 641 [I-D.chakrabarti-nordmark-6man-efficient-nd] adds an 'E' bit in the 642 Router Advertisement flag, as well as a new Registrar Address Option 643 (RAO). These fields are probably pertinent to LLNs inclusion into a 644 revised 6LoWPAN ND should be studied. If the new 6LoWPAN flows 645 require a change of behaviour (e.g. registering the Target of the NS 646 message) then the RA must indicate that the router supports the new 647 capability, and the NS must indicate that the Target is registered as 648 opposed to the Source in an unequivocal fashion. 650 There is some amount of duplication between the options in the RPL 651 DIO [RFC6550] and the options in the ND RA messages. At the same 652 time, there are a number of options, including the 6LoWPAN Context 653 Option (6CO) [RFC6775], the MTU and the SLLA Options [RFC4861] that 654 can only be found in the RA messages. Considering that these options 655 are useful for a joining node, the recommendation would be to 656 associate the RA messages to the join beacon, and make them rare when 657 the network is stable. On the other hand, the DIO message is to be 658 used as the propagated heartbeat of the RPL network and provide the 659 sense of time and liveliness. 661 RAs should also be issued and the information therein propagated when 662 a change occurs in the information therein, such as a router or a 663 prefix lifetime. 665 A.3. RPL DODAG Information Object (DIO) 667 If the RPL root serves as 6LBR, it makes sense to add at least a bit 668 of information in the DIO to signal so. A Registrar Address Option 669 (RAO) may also be considered for addition. 671 A.4. ND Enhanced Address Registration Option (EARO) 673 The ARO option contains a Unique ID that is supposed to identify the 674 device across multiple registrations. It is envisioned that the 675 device could form a single CGA-based Unique Interface ID (CUID) to 676 securely bind all of its addresses. The CUID would be used as Unique 677 Interface Identifier in the ARO option and to form a Link-Local 678 address that would be deemed unique regardless of the Link type. 679 Provided that the relevant cryptographic material is passed to the 680 6LBR upon the first registration or on-demand at a later time, the 681 6LBR can validate that a Node is effectively the owner of a CUID, and 682 ensure that the ownership of an Address stays with the CUID that 683 registered it first. 685 This option is designed to be used with standard NS and NA messages 686 between backbone Routers as well as between nodes and 6LRs over the 687 LLN and between the 6LBR and the 6BBR over whatever IP link they use 688 to communicate. 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Type | Length | Status | RPLInstanceID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |Res|P|N| IDS |T| TID | Registration Lifetime | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | 698 ~ Unique Interface Identifier (variable length) ~ 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Figure 3: EARO 704 The representation above is based on 705 [I-D.chakrabarti-nordmark-6man-efficient-nd]. Only the proposed 706 changes from that specification are discussed below but the 707 expectation is that 6LoWPAN ND and Efficient ND converge on the ARO 708 format. 710 Status: 8-bit integer. A new value of 3 is suggested to indicate a 711 rejection due to an obsolete TID, typically an indication of a 712 movement. 714 RPLInstanceID: 8-bit integer. This field is set to 0 when unused. 715 Otherwise it contains the RPLInstanceID for which this address is 716 registered, as specified in RPL [RFC6550], and discussed in 717 particular in section 3.1.2. 719 P: One bit flag. When the bit is set, the address being registered 720 is Target of the NS as opposed to the Source, for instance to 721 enable ND proxy operation. 723 N: One bit flag. Set if the device moved. If not set, the 6BBR will 724 refrain from sending gratuitous NA(O) or other form of distributed 725 ND cache clean-up over the backbone. For instance, the flag 726 should be reset after the DAD operation upon address formation. 728 Authors' Addresses 730 Pascal Thubert (editor) 731 Cisco Systems, Inc 732 Building D 733 45 Allee des Ormes - BP1200 734 MOUGINS - Sophia Antipolis 06254 735 FRANCE 737 Phone: +33 497 23 26 34 738 Email: pthubert@cisco.com 740 Peter van der Stok 741 consultant 743 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 744 Email: consultancy@vanderstok.org 745 URI: www.vanderstok.org