idnits 2.17.1 draft-thubert-6lo-rfc6775-update-reqs-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 (October 27, 2014) is 3461 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: 'RFC3775' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC6655' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'I-D.hong-6lo-ipv6-over-nfc' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6lo-dect-ule' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-07) exists of draft-chakrabarti-nordmark-6man-efficient-nd-04 == Outdated reference: A later version (-03) exists of draft-hong-6lo-ipv6-over-nfc-01 == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-00 == Outdated reference: A later version (-17) exists of draft-ietf-6lo-btle-02 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-01 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-00 Summary: 3 errors (**), 0 flaws (~~), 23 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 October 27, 2014 5 Expires: April 28, 2015 7 Requirements for an update to 6LoWPAN ND 8 draft-thubert-6lo-rfc6775-update-reqs-05 10 Abstract 12 Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups 13 suggest that enhancements to the 6LoWPAN ND mechanism are now needed. 14 This document elaborates on those requirements and suggests 15 approaches to serve them. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 28, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4.1. Requirements Related to Mobility . . . . . . . . . . . . . 5 55 4.2. Requirements Related to Routing Protocols . . . . . . . . 6 56 4.3. Requirements Related to the Variety of Low-Power Link types 6 57 4.4. Requirements Related to Proxy Operations . . . . . . . . . 7 58 4.5. Requirements Related to Security . . . . . . . . . . . . . 7 59 4.6. Requirements Related to Low-Power devices . . . . . . . . 8 60 4.7. Requirements Related to Scalability . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 67 Appendix A. Suggested Changes to Protocol Elements . . . . . . . . 12 68 Appendix A.1. ND Neighbor Solicitation (NS) . . . . . . . . . . 12 69 Appendix A.2. ND Router Advertisement (RA) . . . . . . . . . . 12 70 Appendix A.3. RPL DODAG Information Object (DIO) . . . . . . . 13 71 Appendix A.4. ND Enhanced Address Registration Option (EARO) . 13 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 A number of use cases, including the Industrial Internet, require a 77 large scale deployment of sensors that can not be realized with wires 78 and is only feasible over wireless Low power and Lossy Network (LLN) 79 technologies. When simpler hub-and-spoke topologies are not 80 sufficient for the expected throughput and density, mesh networks 81 must be deployed, which implies the concepts of hosts and routers, 82 whether operated at Layer-2 or Layer-3. 84 The IETF has designed the LLN host-to-router and router-to-router 85 protocol that supports address assignment and the router-to-router 86 protocol that supports reachability across Route-Over LLNs in 87 different Areas. It was clear for both efforts that the scalability 88 requirements could only be met with IPv6 [RFC2460], and there is no 89 fundamental contradiction between those protocols to that regard. 91 While DHCPv6 is still a viable option in LLNs, the new IETF standard 92 that supports address assignment specifically for LLNs is 6LoWPAN ND, 93 the Neighbor Discovery Optimization for Low-power and Lossy Networks 94 [RFC6775]. 6LoWPAN ND was designed as a stand-alone mechanism 95 separately from its IETF routing counterpart, the IPv6 Routing 96 Protocol for Low power and Lossy Networks [RFC6550] (RPL), and the 97 interaction between the 2 protocols was not defined. 99 The 6TiSCH WG is now considering an architecture [I-D.ietf-6tisch- 100 architecture] whereby a 6LowPAN ND host could connect to the Internet 101 via a RPL Network, but this requires additions to the protocol to 102 support mobility and reachability in a secured and manageable 103 environment. 105 At the same time, new work at 6MAN on Efficiency aware IPv6 Neighbor 106 Discovery Optimizations [I-D.chakrabarti-nordmark-6man-efficient-nd] 107 suggests that 6LoWPAN ND can be extended to other types of networks 108 on top of the Low power and Lossy Networks (LLNs) for which it was 109 already defined. The value of such extension is especially apparent 110 in the case of mobile wireless devices, to reduce the multicast 111 operations that are related to classical ND ([RFC4861], [RFC4862]) 112 and plague the wireless medium. In this context also, there is a 113 need for additions to the protocol. 115 The Optimistic Duplicate Address Detection [RFC4429] (ODAD) 116 specification details how an address can be used before a Duplicate 117 Address Detection (DAD) is complete, and insists that an address that 118 is TENTATIVE should not be associated to a Source Link-Layer Address 119 Option in a Neighbor Solicitation message. As we expect the 6LoWPAN 120 ND protocol for a more general use, it can make sense to keep 121 respecting that rule, which is another change to the specification. 123 This document suggests a limited evolution to [RFC6775] so as to 124 allow operation of a 6LoWPAN ND node as a leaf in a RPL network. It 125 also suggests a more generalized use of the information in the ARO 126 option outside of the strict LLN domain, for instance over a 127 converged backbone. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 Readers are expected to be familiar with all the terms and concepts 136 that are discussed in "Neighbor Discovery for IP version 6" 137 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 138 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 139 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 140 Neighbor Discovery Optimization for Low-power and Lossy Networks 141 [RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4 142 Networks" [RFC4944]. 144 Additionally, this document uses terminology from 6TiSCH [I-D.ietf- 145 6tisch-terminology] and ROLL [RFC7102]. 147 3. Overview 149 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] expects that 150 a 6LoWPAN device can connect as a leaf to a RPL network, where the 151 leaf support is the minimal functionality to connect as a host to a 152 RPL network without the need to participate to the full routing 153 protocol. The support of leaf can be implemented as a minor 154 increment to 6LoWPAN ND, with the additional capability to carry a 155 sequence number that is used to track the movements of the device, 156 and optionally some information about the RPL topology that this 157 device will join. 159 The scope of the 6TiSCH Architecture is a Backbone Link that 160 federates multiple LLNs as a single IPv6 Multi-Link Subnet. Each LLN 161 in the subnet is anchored at a Backbone Router (6BBR). The Backbone 162 Routers interconnect the LLNs over the Backbone Link and emulate that 163 the LLN nodes are present on the Backbone by proxy-ND operations. An 164 LLN node can move freely from an LLN Route-Over mesh anchored at a 165 Backbone Router to another anchored at a same or a different Backbone 166 Router inside the Multi-Link Subnet and conserve its addresses. 168 ---+------------------------ 169 | Plant Network 170 | 171 +-----+ 172 | | Gateway 173 | | 174 +-----+ 175 | 176 | Backbone Link (with VLANs) 177 +--------------------+------------------+ 178 | | | 179 +-----+ +-----+ +-----+ 180 | | Backbone | | Backbone | | Backbone 181 | | router | | router | | router 182 +-----+ +-----+ +-----+ 183 | | | | | | 184 0 0 0 0 0 (6LBR == RPL root) 185 o o o o o o o o o o o o o o 186 o o o o o o o o o o (6LR == RPL router) 187 o o o o o o o z 188 o o o o o z 189 RPL Instances (6LoWPAN Host == RPL leaf) 191 The root of the RPL topology is logically separated from the 6BBR 192 that is used to connect the RPL topology to the backbone. The RPL 193 root can use Efficient ND as the interface to register an LLN node in 194 its topology to the 6BBR for whatever operation the 6BBR performs, 195 such as ND proxy operations, or injection in a routing protocol. It 196 results that, as illustrated in Figure 2, the periodic signaling 197 could start at the leaf node with 6LoWPAN ND, then would be carried 198 over RPL to the RPL root, and then with Efficient-ND to the 6BBR. 199 Efficient ND being an adaptation of 6LoWPAN ND, it makes sense to 200 keep those two homogeneous in the way they use the source and the 201 target addresses in the Neighbor Solicitation (NS) messages for 202 registration, as well as in the options that they use for that 203 process. 205 6LoWPAN Node 6LR 6LBR 6BBR 206 (RPL leaf) (router) (root) 207 | | | | 208 | 6LoWPAN ND |6LoWPAN ND+RPL | Efficient ND | IPv6 ND 209 | LLN link |Route-Over mesh| IPv6 link | Backbone 210 | | | | 211 | NS(ARO) | | | 212 |-------------->| | | 213 | 6LoWPAN ND | DAR (then DAO)| | 214 | |-------------->| | 215 | | | NS(ARO) | 216 | | |-------------->| 217 | | | | DAD 218 | | | |------> 219 | | | | 220 | | | NA(ARO) | 221 | | |<--------------| 222 | | DAC | | 223 | |<--------------| | 224 | NA(ARO) | | | 225 |<--------------| | | 227 As the network builds up, a node should start as a leaf to join the 228 RPL network, and may later turn into both a RPL-capable router and a 229 6LR, so as to accept leaf nodes to recursively join the network. 231 Section 5 of the 6TiSCH architecture [I-D.ietf-6tisch-architecture] 232 provides more information on the need to update the protocols that 233 sustain the requirements in the next section. 235 4. Requirements 237 4.1. Requirements Related to Mobility 239 Due to the nature of LLN networks, even a fixed 6LoWPAN Node may 240 change its point of attachment (a 6LR) and may not be able to notify 241 the 6LR that it has disconnected from. It results that the previous 242 6LR may still attract traffic that it cannot deliver any more. When 243 the 6LR changes, there is thus a need to identify stale states and 244 restore reachability timely. 246 Req1.1: Upon a change of point of attachment, connectivity via a new 247 6LR MUST be restored timely without the need to de-register from the 248 previous 6LR. 250 Req1.2: For that purpose, the protocol MUST enable to differentiate 251 multiple registrations from a same 6LoWPAN Node from two different 252 6LoWPAN Nodes claiming a same address. 254 Req1.3: This information MUST be passed from the 6LR to the 6LBR, and 255 the 6LBR SHOULD be able to clean up the stale state asynchronously in 256 the previous 6LR. 258 Req1.4: A 6LoWPAN Node SHOULD also be capable to register a same 259 Address to multiple 6LRs, and this, concurrently. 261 4.2. Requirements Related to Routing Protocols 263 The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN 264 mesh. An LLN route-over mesh is typically based on RPL, which is the 265 routing protocol that was defined at the IETF for this particular 266 purpose. It derives that in this scenario, the 6LR would classically 267 support RPL. One goal is that a 6LoWPAN Node attached via ND to a 268 RPL-capable 6LR would not need to participate to the RPL protocol to 269 obtain reachability via the 6LR. An additional goal would be to 270 obtain reachability via other routing protocols through a same ND- 271 based abstraction. 273 Related requirements are: 275 Req2.1: The ND registration method SHOULD be extended in such a 276 fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over 277 RPL and obtain reachability to that Address over the RPL domain. 279 Req2.2: The Address Registration Option that is used in the ND 280 registration SHOULD be extended to carry enough information to 281 generate a DAO message as specified in [RFC6550] section 6.4, in 282 particular the capability to compute a DAOSequence and, as an option, 283 a RPLInstanceID. 285 Req2.3: Depending on their applicability to LLNs, other standard mesh 286 /MANET protocols MAY be considered as well. 288 Req2.4: Multicast operations SHOULD be supported and optimized. 289 Groups MAY be formed by device type (e.g. routers, street lamps), 290 location (Geography, RPL sub-tree), or both. RPL already has the 291 capability to advertise multicast groups; whether ND is appropriate 292 for the registration to the 6BBR is to be defined, considering the 293 additional burden of supporting the Multicast Listener Discovery 294 Version 2 [RFC3810] (MLDv2) for IPv6. 296 4.3. Requirements Related to the Variety of Low-Power Link types 297 6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in 298 particular the capability to derive a unique Identifier from a 299 globally unique MAC-64 address. At this point, the 6lo Working Group 300 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 301 to other link types ITU-T G.9959 [I-D.brandt-6man-lowpanz], Master- 302 Slave/Token-Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy [I-D 303 .ietf-6lo-dect-ule], Near Field Communication [I-D.hong-6lo-ipv6 304 -over-nfc], as well as IEEE1901.2 Narrowband Powerline Communication 305 Networks [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and 306 BLUETOOTH(R) Low Energy [I-D.ietf-6lo-btle]. 308 Related requirements are: 310 Req3.1: The support of the registration mechanism SHOULD be extended 311 to more LLN links, matching at least the links that are considered by 312 6lo as well as other popular Low-Power links such as Low-Power Wi-Fi. 314 Req3.2: As part of this extension, a mechanism to compute a unique 315 Identifier should be provided, with the capability to form a Link- 316 Local Address that can not be a duplicate. The Identifier SHOULD be 317 unique at least to the domain where an Address formed by this device 318 may be advertised through ND mechanisms. 320 Req3.3: The Address Registration Option used in the ND registration 321 SHOULD be extended to carry the relevant forms of unique Identifier. 323 4.4. Requirements Related to Proxy Operations 325 Sleeping devices may not be able to answer themselves to a lookup 326 from a node that uses classical ND on a backbone and may need a proxy 327 operation by a 6BBR. Additionally, the device may need to rely on the 328 6LBR to perform that registration to the 6BBR. 330 Related requirements are: 332 Req4.1: The registration mechanism SHOULD enable a third party to 333 proxy register an Address on behalf of a 6LoWPAN node that may be 334 sleeping or located deeper in an LLN mesh. 336 4.5. Requirements Related to Security 338 In order to guarantee the operations of the 6LoWPAN ND flows, the 339 spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a 340 node successfully registers an address, 6LoWPAN ND should provide 341 energy-efficient means to protect that ownership even if the node is 342 sleeping. In particular, the 6LR and the 6LBR then should be able to 343 verify whether a subsequent registration for a same Address comes 344 from a same node or is a duplicate. 346 Related requirements are: 348 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 349 the 6LR, 6LBR and 6BBR to authenticate and authorize one another for 350 their respective roles, as well as with the 6LoWPAN Node for the role 351 of 6LR. 353 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 354 the 6LR and the 6LBR to validate whether a new registration 355 corresponds to a same 6LoWPAN Node, and, if not, determine the 356 rightful owner, and deny or clean-up the registration that is deemed 357 in excess. 359 Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet 360 sizes. In particular, the NS, NA, DAR and DAC messages for a re- 361 registration flow SHOULD NOT exceed 80 octets so as to fit in a 362 secured IEEE802.15.4 frame. 364 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 365 computationally intensive on the LoWPAN Node CPU. When a Key hash 366 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 367 preferred. 369 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 370 SHOULD be minimized. 372 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use 373 at both Layer 2 and Layer 3, and SHOULD enable the reuse of security 374 code that has to be present on the device for upper layer security 375 such as TLS. 377 Req5.7: Public key and signature sizes SHOULD be minimized while 378 maintaining adequate confidentiality and data origin authentication 379 for multiple types of applications with various degrees of 380 criticality. 382 4.6. Requirements Related to Low-Power devices 384 The ND registration method is designed to save energy on Low-Power 385 devices, and in particular enable duty-cycled devices that are 386 sleeping most of the time and not capable to defend their own 387 Addresses against always-on devices. 389 Related requirements are: 391 Req6.1: The registration mechanism SHOULD be applicable to a Low- 392 Power device regardless of the link type, and enable a 6BBR to 393 operate as a proxy to defend the registered Addresses on its behalf. 395 Req6.2: The registration mechanism SHOULD enable long sleep 396 durations, in the order of multiple days to a month, for devices 397 capable of operating over the course of ten or more years without the 398 need to recharge or replace the batteries. 400 4.7. Requirements Related to Scalability 401 Use cases from Automatic Meter Reading (AMR, collection tree 402 operations) and Advanced Metering Infrastructure (AMI, bi-directional 403 communication to the meters) indicate the needs for a large number of 404 LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected 405 to the 6LBR over a large number of LLN hops (e.g. 15). 407 Related requirements are: 409 Req7.1: The registration mechanism SHOULD enable a single 6LBR to 410 register multiple thousands of devices. 412 Req7.2: The timing of the registration operation should allow for a 413 large latency such as found in LLNs with ten and more hops. 415 5. Security Considerations 417 This specification expects that the link layer is sufficiently 418 protected, either by means of physical or IP security for the 419 Backbone Link or MAC sublayer cryptography. In particular, it is 420 expected that the LLN MAC provides secure unicast to/from the 421 Backbone Router and secure broadcast from the Backbone Router in a 422 way that prevents tempering with or replaying the RA messages. 423 Still, Section 4.5 has a requirement for a mutual authentication and 424 authorization for a role for 6LRs, 6LBRs and 6BBRs. 426 This documents also suggests in Appendix Appendix A.4 that a 6LoWPAN 427 Node could form a single Unique Interface ID (CUID) based on 428 cryptographic techniques similar to CGA. The CUID would be used as 429 Unique Interface Identifier in the ARO option and new Secure ND 430 procedures would be proposed to use it as opposed to the source IPv6 431 address to secure the binding between an Address and its owning Node, 432 and enforce First/Come-First/Serve at the 6LBR. 434 6. IANA Considerations 436 This draft does not require an IANA action. 438 7. Acknowledgments 440 The author wishes acknowledge the contributions by Samita 441 Chakrabarti, Erik Normark, JP Vasseur, Eric Levy-Abegnoli, Patrick 442 Wetterwald, Thomas Watteyne, and Behcet Sarikaya. 444 8. References 446 8.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 452 6 (IPv6) Specification", RFC 2460, December 1998. 454 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 455 in IPv6", RFC 3775, June 2004. 457 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 458 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 460 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 461 Architecture", RFC 4291, February 2006. 463 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 464 for IPv6", RFC 4429, April 2006. 466 [RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control 467 Message Protocol (ICMPv6) for the Internet Protocol 468 Version 6 (IPv6) Specification", RFC 4443, March 2006. 470 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 471 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 472 September 2007. 474 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 475 Address Autoconfiguration", RFC 4862, September 2007. 477 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler, 478 "Transmission of IPv6 Packets over IEEE 802.15.4 479 Networks", RFC 4944, September 2007. 481 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support 482 in IPv6", RFC 6275, July 2011. 484 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 485 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 486 September 2011. 488 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 489 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 490 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 491 Lossy Networks", RFC 6550, March 2012. 493 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 494 Transport Layer Security (TLS)", RFC 6655, July 2012. 496 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, 497 "Neighbor Discovery Optimization for IPv6 over Low-Power 498 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 499 November 2012. 501 [RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The 502 Locator/ID Separation Protocol (LISP)", RFC 6830, January 503 2013. 505 8.2. Informative References 507 [I-D.brandt-6man-lowpanz] 508 Brandt, A. and J. Buron, "Transmission of IPv6 packets 509 over ITU-T G.9959 Networks", Internet-Draft draft-brandt- 510 6man-lowpanz-02, June 2013. 512 [I-D.chakrabarti-nordmark-6man-efficient-nd] 513 Chakrabarti, S., Nordmark, E., Thubert, P. and M. 514 Wasserman, "Wired and Wireless IPv6 Neighbor Discovery 515 Optimizations", Internet-Draft draft-chakrabarti-nordmark- 516 6man-efficient-nd-04, October 2013. 518 [I-D.hong-6lo-ipv6-over-nfc] 519 Hong, Y., Choi, Y., Youn, J., Kim, D. and J. Choi, 520 "Transmission of IPv6 Packets over Near Field 521 Communication", Internet-Draft draft-hong-6lo-ipv6-over- 522 nfc-01, August 2014. 524 [I-D.ietf-6lo-6lobac] 525 Lynn, K., Martocci, J., Neilson, C. and S. Donaldson, 526 "Transmission of IPv6 over MS/TP Networks", Internet-Draft 527 draft-ietf-6lo-6lobac-00, July 2014. 529 [I-D.ietf-6lo-btle] 530 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 531 Shelby, Z. and C. Gomez, "Transmission of IPv6 Packets 532 over BLUETOOTH(R) Low Energy", Internet-Draft draft-ietf- 533 6lo-btle-02, June 2014. 535 [I-D.ietf-6lo-dect-ule] 536 Mariager, P., Petersen, J., Shelby, Z., Logt, M. and D. 537 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 538 Energy", Internet-Draft draft-ietf-6lo-dect-ule-00, June 539 2014. 541 [I-D.ietf-6tisch-architecture] 542 Thubert, P., Watteyne, T. and R. Assimiti, "An 543 Architecture for IPv6 over the TSCH mode of IEEE 544 802.15.4e", Internet-Draft draft-ietf-6tisch- 545 architecture-01, February 2014. 547 [I-D.ietf-6tisch-terminology] 548 Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, 549 "Terminology in IPv6 over the TSCH mode of IEEE 550 802.15.4e", Internet-Draft draft-ietf-6tisch- 551 terminology-00, November 2013. 553 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 554 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 555 over IEEE 1901.2 Narrowband Powerline Communication 556 Networks", Internet-Draft draft-popa-6lo-6loplc-ipv6-over- 557 ieee19012-networks-00, March 2014. 559 [RFC3610] Whiting, D., Housley, R. and N. Ferguson, "Counter with 560 CBC-MAC (CCM)", RFC 3610, September 2003. 562 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. 563 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 564 RFC 3963, January 2005. 566 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 567 Neighbor Discovery (SEND)", RFC 3971, March 2005. 569 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 570 RFC 3972, March 2005. 572 [RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery 573 Proxies (ND Proxy)", RFC 4389, April 2006. 575 [RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6 576 over Low-Power Wireless Personal Area Networks (6LoWPANs): 577 Overview, Assumptions, Problem Statement, and Goals", RFC 578 4919, August 2007. 580 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 581 Lossy Networks", RFC 7102, January 2014. 583 Appendix A. Suggested Changes to Protocol Elements 585 Appendix A.1. ND Neighbor Solicitation (NS) 587 The NS message used for registration should use a source address that 588 respects the rules in [RFC6775], [RFC4861], and [RFC4429] for DAD. 589 The SLLA Option may be present but only if the address passed DAD, 590 and it is used to allow the 6LR to respond as opposed to as a 591 registration mechanism. 593 The address that is being registered is the target address in the NS 594 message and the TLLA Option must be present. 596 Appendix A.2. ND Router Advertisement (RA) 598 [I-D.chakrabarti-nordmark-6man-efficient-nd] adds an 'E' bit in the 599 Router Advertisement flag, as well as a new Registrar Address Option 600 (RAO). These fields are probably pertinent to LLNs inclusion into a 601 revised 6LoWPAN ND should be studied. If the new 6LoWPAN flows 602 require a change of behaviour (e.g. registering the Target of the NS 603 message) then the RA must indicate that the router supports the new 604 capability, and the NS must indicate that the Target is registered as 605 opposed to the Source in an unequivocal fashion. 607 There is some amount of duplication between the options in the RPL 608 DIO [RFC6550] and the options in the ND RA messages. At the same 609 time, there are a number of options, including the 6LoWPAN Context 610 Option (6CO) [RFC6775], the MTU and the SLLA Options [RFC4861] that 611 can only be found in the RA messages. Considering that these options 612 are useful for a joining node, the recommendation would be to 613 associate the RA messages to the join beacon, and make them rare when 614 the network is stable. On the other hand, the DIO message is to be 615 used as the propagated heartbeat of the RPL network and provide the 616 sense of time and liveliness. 618 RAs should also be issued and the information therein propagated when 619 a change occurs in the information therein, such as a router or a 620 prefix lifetime. 622 Appendix A.3. RPL DODAG Information Object (DIO) 624 If the RPL root serves as 6LBR, it makes sense to add at least a bit 625 of information in the DIO to signal so. A Registrar Address Option 626 (RAO) may also be considered for addition. 628 Appendix A.4. ND Enhanced Address Registration Option (EARO) 630 The ARO option contains a Unique ID that is supposed to identify the 631 device across multiple registrations. It is envisioned that the 632 device could form a single CGA-based Unique Interface ID (CUID) to 633 securely bind all of its addresses. The CUID would be used as Unique 634 Interface Identifier in the ARO option and to form a Link-Local 635 address that would be deemed unique regardless of the Link type. 636 Provided that the relevant cryptographic material is passed to the 637 6LBR upon the first registration or on-demand at a later time, the 638 6LBR can validate that a Node is effectively the owner of a CUID, and 639 ensure that the ownership of an Address stays with the CUID that 640 registered it first. 642 This option is designed to be used with standard NS and NA messages 643 between backbone Routers as well as between nodes and 6LRs over the 644 LLN and between the 6LBR and the 6BBR over whatever IP link they use 645 to communicate. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Type | Length | Status | RPLInstanceID | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 |Res|P|N| IDS |T| TID | Registration Lifetime | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 ~ Unique Interface Identifier (variable length) ~ 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 The representation above is based on [I-D.chakrabarti-nordmark-6man- 660 efficient-nd]. Only the proposed changes from that specification are 661 discussed below but the expectation is that 6LoWPAN ND and Efficient 662 ND converge on the ARO format. 664 Status: 8-bit integer. A new value of 3 is suggested to indicate a 665 rejection due to an obsolete TID, typically an indication of a 666 movement. 668 RPLInstanceID: 8-bit integer. This field is set to 0 when unused. 669 Otherwise it contains the RPLInstanceID for which this address is 670 registered, as specified in RPL [RFC6550], and discussed in 671 particular in section 3.1.2. 673 P: One bit flag. When the bit is set, the address being registered 674 is Target of the NS as opposed to the Source, for instance to 675 enable ND proxy operation. 677 N: One bit flag. Set if the device moved. If not set, the 6BBR will 678 refrain from sending gratuitous NA(O) or other form of distributed 679 ND cache clean-up over the backbone. For instance, the flag 680 should be reset after the DAD operation upon address formation. 682 Author's Address 684 Pascal Thubert, editor 685 Cisco Systems, Inc 686 Building D 687 45 Allee des Ormes - BP1200 688 MOUGINS - Sophia Antipolis, 06254 689 FRANCE 691 Phone: +33 497 23 26 34 692 Email: pthubert@cisco.com