idnits 2.17.00 (12 Aug 2021) /tmp/idnits8061/draft-ietf-6lo-multicast-registration-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC9010, but the abstract doesn't seem to directly say this. It does mention RFC9010 though, so this could be OK. -- The draft header indicates that this document updates RFC6553, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (2 March 2022) is 73 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 6550, 6553, 8505, 9010 (if approved) 2 March 2022 5 Intended status: Standards Track 6 Expires: 3 September 2022 8 IPv6 Neighbor Discovery Multicast Address Listener Registration 9 draft-ietf-6lo-multicast-registration-04 11 Abstract 13 This document updates RFC 8505 to enable a listener to register an 14 IPv6 anycast or and subscribe to an IPv6 multicast address; the draft 15 updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a 16 new support for anycast addresses in Storing and Non-Storing Modes. 17 This document extends RFC 9010 to enable the 6LR to inject the 18 anycast and multicast addresses in RPL. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 3 September 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 9 60 5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 10 62 5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 10 63 5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 11 64 5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 12 65 6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 12 66 6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 13 67 6.2. New EDAR Message Flag field . . . . . . . . . . . . . . . 14 68 6.3. Registering Extensions . . . . . . . . . . . . . . . . . 15 69 7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 16 70 8. Leveraging RFC 8929 . . . . . . . . . . . . . . . . . . . . . 17 71 9. Deployment considerations . . . . . . . . . . . . . . . . . . 17 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 20 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 12.1. New EDAR Message Flags Subregistry . . . . . . . . . . . 20 76 12.2. New EARO flags . . . . . . . . . . . . . . . . . . . . . 21 77 12.3. New RTO flags . . . . . . . . . . . . . . . . . . . . . 21 78 12.4. New RPL Mode of Operation . . . . . . . . . . . . . . . 22 79 12.5. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 22 80 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 81 14. Normative References . . . . . . . . . . . . . . . . . . . . 22 82 15. Informative References . . . . . . . . . . . . . . . . . . . 25 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 85 1. Introduction 87 The design of Low Power and Lossy Networks (LLNs) is generally 88 focused on saving energy, which is the most constrained resource of 89 all. Other design constraints, such as a limited memory capacity, 90 duty cycling of the LLN devices and low-power lossy transmissions, 91 derive from that primary concern. The radio (both transmitting or 92 simply listening) is a major energy drain and the LLN protocols must 93 be adapted to allow the nodes to remain sleeping with the radio 94 turned off at most times. 96 The "Routing Protocol for Low Power and Lossy Networks" [RFC6550] 97 (RPL) to provide IPv6 [RFC8200] routing services within such 98 constraints. To save signaling and routing state in constrained 99 networks, the RPL routing is only performed along a Destination- 100 Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a 101 Root node, as opposed to along the shortest path between 2 peers, 102 whatever that would mean in each LLN. 104 This trades the quality of peer-to-peer (P2P) paths for a vastly 105 reduced amount of control traffic and routing state that would be 106 required to operate an any-to-any shortest path protocol. 107 Additionally, broken routes may be fixed lazily and on-demand, based 108 on dataplane inconsistency discovery, which avoids wasting energy in 109 the proactive repair of unused paths. 111 Section 12 of [RFC6550] details the "Storing Mode of Operation with 112 multicast support" with source-independent multicast routing in RPL. 114 The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] 115 [RFC4862] was defined for serial links and shared transit media such 116 as Ethernet at a time when broadcast was cheap on those media while 117 memory for neighbor cache was expensive. It was thus designed as a 118 reactive protocol that relies on caching and multicast operations for 119 the Address Discovery (aka Lookup) and Duplicate Address Detection 120 (DAD) of IPv6 unicast addresses. Those multicast operations 121 typically impact every node on-link when at most one is really 122 targeted, which is a waste of energy, and imply that all nodes are 123 awake to hear the request, which is inconsistent with power saving 124 (sleeping) modes. 126 The original 6LoWPAN ND, "Neighbor Discovery Optimizations for 127 6LoWPAN networks" [RFC6775], was introduced to avoid the excessive 128 use of multicast messages and enable IPv6 ND for operations over 129 energy-constrained nodes. [RFC6775] changes the classical IPv6 ND 130 model to proactively establish the Neighbor Cache Entry (NCE) 131 associated to the unicast address of a 6LoWPAN Node (6LN) in the a 132 6LoWPAN Router(s) (6LR) that serves it. To that effect, [RFC6775] 133 defines a new Address Registration Option (ARO) that is placed in 134 unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) 135 messages between the 6LN and the 6LR. 137 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 138 updates [RFC6775] into a generic Address Registration mechanism that 139 can be used to access services such as routing and ND proxy and 140 introduces the Extended Address Registration Option (EARO) for that 141 purpose. This provides a routing-agnostic interface for a host to 142 request that the router injects a unicast IPv6 address in the local 143 routing protocol and provide return reachability for that address. 145 "Routing for RPL Leaves" [RFC9010] provides the router counterpart of 146 the mechanism for a host that implements [RFC8505] to inject its 147 unicast Unique Local Addresses (ULAs) and Global Unicast Addresses 148 (GUAs) in RPL. But though RPL also provides multicast routing, 149 6LoWPAN ND supports only the registration of unicast addresses and 150 there is no equivalent of [RFC9010] to specify the 6LR behavior upon 151 the registration of one or more multicast address. 153 The "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" 154 [RFC3810] enables the router to learn which node listens to which 155 multicast address, but as the classical IPv6 ND protocol, MLD relies 156 on multicasting Queries to all nodes, which is unfit for low power 157 operations. As for IPv6 ND, it makes sense to let the 6LNs control 158 when and how they maintain the state associated to their multicast 159 addresses in the 6LR, e.g., during their own wake time. In the case 160 of a constrained node that already implements [RFC8505] for unicast 161 reachability, it makes sense to extend to that support to register 162 the multicast addresses they listen to. 164 This specification extends [RFC8505] and [RFC9010] to add the 165 capability for the 6LN to register anycast and multicast addresses 166 and for the 6LR to inject them in RPL. 168 2. Terminology 170 2.1. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 2.2. References 180 This document uses terms and concepts that are discussed in: 182 * "Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 183 Stateless address Autoconfiguration" [RFC4862], 185 * Neighbor Discovery Optimization for Low-Power and Lossy Networks 186 [RFC6775], as well as 188 * "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 189 and 191 * "Using RPI Option Type, Routing Header for Source Routes, and 192 IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008]. 194 2.3. Glossary 196 This document uses the following acronyms: 198 6BBR 6LoWPAN Backbone Router 199 6BBR 6LoWPAN Border Router 200 6LN 6LoWPAN Node 201 6LR 6LoWPAN Router 202 6CIO Capability Indication Option 203 AMC Address Mapping Confirmation 204 AMR Address Mapping Request 205 ARO Address Registration Option 206 DAC Duplicate Address Confirmation 207 DAD Duplicate Address Detection 208 DAR Duplicate Address Request 209 EARO Extended Address Registration Option 210 EDAC Extended Duplicate Address Confirmation 211 EDAR Extended Duplicate Address Request 212 DODAG Destination-Oriented Directed Acyclic Graph 213 IR Ingress Replication 214 LLN Low-Power and Lossy Network 215 NA Neighbor Advertisement 216 NCE Neighbor Cache Entry 217 ND Neighbor Discovery 218 NS Neighbor Solicitation 219 ROVR Registration Ownership Verifier 220 RTO RPL Target Option 221 RA Router Advertisement 222 RS Router Solicitation 223 TID Transaction ID 224 TIO Transit Information Option 226 3. Overview 228 This specification inherits from [RFC6550], [RFC8505], and [RFC8505] 229 to provide additional capabilities for anycast and multicast. Unless 230 specified otherwise therein, the behavior of the 6LBR that acts as 231 RPL Root, of the intermediate routers down the RPL graph, of the 6LR 232 that act as access routers and of the 6LNs that are the RFC-unaware 233 destinations, is the same as for unicast. In particular, forwarding 234 a packet happens as specified in section 11 of [RFC6550], including 235 loop avoidance and detection, though in the case of multicast 236 multiple copies might be generated. 238 [RFC8505] is a pre-requisite to this specification. A node that 239 implements this MUST also implement [RFC8505]. This specification 240 does not introduce a new option; it modifies existing options and 241 updates the associated behaviors to enable the Registration for 242 Multicast Addresses as an extension to [RFC8505]. 244 This specification also extends [RFC6550] and [RFC9010] in the case 245 of a route-over multilink subnet based on the RPL routing protocol, 246 to add multicast ingress replication in Non-Storing Mode and anycast 247 support in both Storing and Non-Storing modes. A 6LR that implements 248 the RPL extensions specified therein MUST also implement [RFC9010]. 250 Figure 1 illustrates the classical situation of an LLN as a single 251 IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root 252 for RPL operations and maintains a registry of the active 253 registrations as an abstract data structure called an Address 254 Registrar for 6LoWPAN ND. 256 The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi 257 [IEEE Std 802.11] and Bluetooth (Low Energy) [IEEE Std 802.15.1], or 258 a Route-Over LLN such as the Wi-SUN mesh [Wi-SUN] that leverages 259 6LoWPAN [RFC4919][RFC6282] and RPL [RFC6550] over [IEEE Std 260 802.15.4]. 262 | 263 ----+-------+------------ 264 | Wire side 265 +------+ 266 | 6LBR | 267 |(Root)| 268 +------+ 269 o o o Wireless side 270 o o o o o o 271 o o o o o o o 272 o o o LLN o +---+ 273 o o o o o |6LR| 274 o o o o o +---+ 275 o o o o o o z 276 o o oo o o +---+ 277 o |6LN| 278 +---+ 280 Figure 1: Wireless Mesh 282 A leaf acting as a 6LN registers its unicast and anycast addresses a 283 RPL router acting as a 6LR, using a layer-2 unicast NS message with 284 an EARO as specified in [RFC8505]. The registration state is 285 periodically renewed by the Registering Node, before the lifetime 286 indicated in the EARO expires. As for unicast IPv6 addresses, the 287 6LR uses an EDAR/EDAR exchange with the 6LBR to notify the 6LBR of 288 the presence of the listeners. 290 With this specification, the 6LNs can now subscribe to the multicast 291 addresses they listen to, using a new M flag in the EARO to signal 292 that the registration is for a multicast address. Multiple 6LN may 293 subscribe to the same multicast address to the same 6LR. Note the 294 use of the term "subscribe": using the EARO registration mechanism, a 295 node registers the unicast addresses that it owns, but subscribes to 296 the multicast addresses that it listens to. 298 With this specification, the 6LNs can also register the anycast 299 addresses they accept, using a new A flag in the EARO to signal that 300 the registration is for an anycast address. As for multicast, 301 multiple 6LN may register the same anycast address to the same 6LR. 303 If the R flag is set in the registration of one or more 6LNs for the 304 same address, the 6LR injects the anycast and multicast addresses in 305 RPL, based on the longest registration lifetime across the active 306 registrations for the address. 308 In the RPL "Storing Mode of Operation with multicast support", the 309 DAO messages for the multicast address percolate along the RPL 310 preferred parent tree and mark a subtree that becomes the multicast 311 tree for that multicast address, with 6LNs that subscribed to the 312 address as the leaves. As prescribed in section 12 of [RFC6550], the 313 6LR forwards a multicast packet as an individual unicast MAC frame to 314 each peer along the multicast tree, excepting to the node it received 315 the packet from. 317 In the new RPL "Non-Storing Mode of Operation with multicast support" 318 that is introduced here, the DAO messages announce the multicast 319 addresses as Targets though never as Transit. The multicast 320 distribution is an ingress replication whereby the Root encapsulates 321 the multicast packets to all the 6LRs that are transit for the 322 multicast address, using the same source-routing header as for 323 unicast targets attached to the respective 6LRs. 325 Broadcasting is typically unreliable in LLNs (no ack) and forces a 326 listener to remain awake, so it generally discouraged. The 327 expectation is thus that in either mode, the 6LRs deliver the 328 multicast packets as individual unicast MAC frames to each of the 329 6LNs that subscribed to the multicast address. 331 With this specification, anycast addresses can be injected in RPL in 332 both Storing and Non-Storing modes. In Storing Mode the RPL router 333 accepts DAO from multiple children for the same anycast address, but 334 only forwards a packet to one of the children. In Non-Storing Mode, 335 the Root maintains the list of all the RPL nodes that announced the 336 anycast address as Target, but forwards a given packet to only one of 337 them. 339 For backward compatibility, this specification allows to build a 340 single DODAG signaled as MOP 1, that conveys anycast, unicast and 341 multicast packets using the same source routing mechanism, more in 342 Section 9. 344 It is also possible to leverage this specification between the 6LN 345 and the 6LR for the registration of unicast, anycast and multicast 346 IPv6 addresses in networks that are not necessarily LLNs, and/or 347 where the routing protocol between the 6LR and above is not 348 necessarily RPL. In that case, the distribution of packets between 349 the 6LR and the 6LNs may effectively rely on a broadcast or multicast 350 support at the lower layer. 352 For instance, it is possible to operate a RPL Instance in the new 353 "Non-Storing Mode of Operation with multicast support" (while 354 possibly signaling a MOP of 1) and use "Multicast Protocol for 355 Low-Power and Lossy Networks (MPL)" [RFC7731] for the multicast 356 operation. MPL floods the DODAG with the multicast messages 357 independently of the RPL DODAG topologies. Two variations are 358 possible: 360 * In one possible variation, all the 6LNs set the R flag in the EARO 361 for a multicast target, upon which the 6LRs send a unicast DAO 362 message to the Root; the Root filters out the multicast messages 363 for which there is no listener and only floods when there is. 365 * In a simpler variation, the 6LNs do not set the R flag and the 366 Root floods all the multicast packets over the whole DODAG. Using 367 configuration, it is also possible to control the behavior of the 368 6LR to ignore the R flag and either always or never send the DAO 369 message, and/or to control the Root and specify which groups it 370 should flood or not flood. 372 Note that if the configuration instructs the 6LR not to send the DAO, 373 then MPL can really by used in conjunction with RPL Storing Mode as 374 well. 376 4. Extending RFC 7400 378 This specification defines a new capability bit for use in the 6CIO 379 as defined by "6LoWPAN-GHC: Generic Header Compression for IPv6 over 380 Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] and 381 extended in [RFC8505] for use in IPv6 ND messages. 383 The new "Registration for Multicast Address Supported" (M) flag 384 indicates to the 6LN that the 6LR accepts multicast address 385 registrations as specified in this document and will ensure that 386 packets for the multicast Registered Address will be routed to the 387 6LNs that registered with the R flag set. 389 Figure 2 illustrates the M flag in its suggested position (8, 390 counting 0 to 15 in network order in the 16-bit array), to be 391 confirmed by IANA. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length = 1 | Reserved |M|A|D|L|B|P|E|G| 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Reserved | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 2: New Capability Bits in the 6CIO 403 New Option Field: 405 M 1-bit flag: "Registration for Multicast and Anycast Addresses 406 Supported" 408 5. Updating RFC 6550 410 5.1. Updating MOP 3 412 RPL supports multicast operations in the "Storing Mode of Operation 413 with multicast support" (MOP 3) which provides source-independent 414 multicast routing in RPL, as prescribed in section 12 of [RFC6550]. 415 MOP 3 is a storing Mode of Operation. This operation builds a 416 multicast tree within the RPL DODAG for each multicast address. This 417 specification provides additional details for the MOP 3 operation. 419 The expectation in MOP 3 is that the unicast traffic also follows the 420 Storing Mode of Operation. But this is rarely the case in LLN 421 deployments of RPL where the "Non-Storing Mode of Operation" (MOP 1) 422 is the norm. Though it is preferred to build separate RPL Instances, 423 one in MOP 1 and one in MOP 3, this specification allows to hybrid 424 the Storing Mode for multicast and Non-Storing Mode for unicast in 425 the same RPL Instance, more in Section 9. 427 5.2. New Non-Storing Multicast MOP 429 This specification adds a "Non-Storing Mode of Operation with 430 multicast support" (MOP to be assigned by IANA) whereby the non- 431 storing Mode DAO to the Root may contain multicast addresses in the 432 RPL Target Option (RTO), whereas the Transit Information Option (TIO) 433 cannot. 435 In that mode, the RPL Root performs an ingress replication (IR) 436 operation on the multicast packets, meaning that it transmits one 437 copy of each multicast packet to each 6LR that is a transit for the 438 multicast target, using the same source routing header and 439 encapsulation as it would for a unicast packet for a RPL Unaware Leaf 440 (RUL) attached to that 6LR. 442 For the intermediate routers, the packet appears as any source routed 443 unicast packet. The difference shows only at the 6LR, that 444 terminates the source routed path and forwards the multicast packet 445 to all 6LNs that registered for the multicast address. 447 For a packet that is generated by the Root, this means that the Root 448 builds a source routing header as shown in section 8.1.3 of 449 [RFC9008], but for which the last and only the last address is 450 multicast. For a packet that is not generated by the Root, the Root 451 encapsulates the multicast packet as per section 8.2.4 of [RFC9008]. 452 In that case, the outer header is purely unicast, and the 453 encapsulated packet is purely multicast. 455 For this new mode as well, this specification allows to enable the 456 operation in a MOP 1 brown field, more in Section 9. 458 5.3. RPL Anycast Operation 460 With multicast, the address has a recognizable format, and a 461 multicast packet is to be delivered to all the active subscribers. 462 In contrast with anycast, the format of the address is not 463 distinguishable from that of unicast. A legacy node may issue a DAO 464 message without setting the A flag, the unicast behaviour may apply 465 to anycast traffic in a subDAGs. A target is routed as anycast by a 466 parent (or the Root) that received at least one DAO message for that 467 target with the A flag set to 1. As for multicast, the freshness 468 comparison cannot apply to an anycast target, and the TID field is 469 ignored. 471 As opposed to multicast, the anycast operation described therein 472 applies to both addresses and prefixes, and the A flag can be set for 473 both. An external destination (address or prefix) that may be 474 injected as a RPL target from multiple border routers SHOULD be 475 injected as anycast in RPL to enable load balancing. A mobile target 476 that is multihomed SHOULD in contrast be advertised as unicast over 477 the multiple interfaces to favor the TID comparision and vs. the 478 multipath load balancing. 480 For either multicast and anycast, there can be multiple registrations 481 from multiple parties, each using a different value of the ROVR field 482 that identifies the individual registration. The 6LR MUST maintain a 483 registration state per value of the ROVR per multicast or anycast 484 address, but inject the route into RPL only once for each address. 485 Since the registrations are considered separate, the check on the TID 486 that acts as registration sequence only applies to the registration 487 with the same ROVR. 489 The 6LRs that inject multicast and anycast routes into RPL may not be 490 synchronized to advertise same value of the Path Sequence in the RPL 491 TIO. It results that the value the Path Sequence is irrelevant when 492 the target is anycast or multicast, and that it MUST be ignored. 494 Like the 6LR, a RPL router in Storing Mode propagates the route to 495 its parent(s) in DAO messages once and only once for each address, 496 but it MUST retain a routing table entry for each of the children 497 that advertised the address. 499 When forwarding multicast packets down the DODAG, the RPL router 500 copies all the children that advertised the address in their DAO 501 messages. In contrast, when forwarding anycast packets down the 502 DODAG, the RPL router MUST copy one and only one of the children that 503 advertised the address in their DAO messages, and forward to one 504 parent if there is no such child. 506 5.4. New RPL Target Option Flags 508 [RFC6550] recognizes a multicast address by its format (as specified 509 in section 2.7 of [RFC4291]) and applies the specified multicast 510 operation if the address is recognized as multicast. This 511 specification updates [RFC6550] to add the M and A flags to the RTO 512 to indicate that the target address is to be processed as multicast 513 or anycast, respectively. 515 An RTO that has the M flag set to 1 is called a multicast RTO. An 516 RTO that has the A flag set to 1 is called an anycast RTO. An RTO 517 that has both the A and the M flags set to 0 is called an unicast 518 RTO. With this specification, the M and A flags are mutually 519 exclusive and MUST NOT be both set to 1. The capability to set both 520 flags is reserved and an RTO that is received with both flags set 521 MUST be ignored. 523 The suggested position for the A and M flags are 2 and 3 counting 524 from 0 to 7 in network order as shown in Figure 3, based on figure 4 525 of [RFC9010] which defines the flags in position 0 and 1: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type = 0x05 | Option Length |F|X|A|M|ROVRsz | Prefix Length | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | | 533 | Target Prefix (Variable Length) | 534 . . 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | | 537 ... Registration Ownership Verifier (ROVR) ... 538 | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 3: Format of the RPL Target Option 543 6. Updating RFC 8505 544 6.1. New EARO flag 546 Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO 547 option defined in [RFC6775]. 549 This specification adds a new M flag to the EARO flags field to 550 signal that the Registered Address is a multicast address. When both 551 the M and the R flags are set, the 6LR that conforms to this 552 specification joins the multicast stream, e.g., by injecting the 553 address in the RPL multicast support which is extended in this 554 specification for Non-Storing Mode. 556 This specification adds a new A flag to the EARO flags field to 557 signal that the Registered Address is an anycast address. When both 558 the A and the R flags are set, the 6LR that conforms to this 559 specification injects the anycast address in the RPL anycast support 560 that is introduced in this specification for both Storing and Non- 561 Storing Modes. 563 Figure 4 illustrates the A and M flags in their suggested positions 564 (2 and 3, respectively, counting 0 to 7 in network order in the 8-bit 565 array), to be confirmed by IANA. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | Status | Opaque | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |Rsv|A|M| I |R|T| TID | Registration Lifetime | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | | 575 ... Registration Ownership Verifier ... 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 4: EARO Option Format 581 New and updated Option Fields: 583 Rsv 2-bit field: reserved, MUST be set to 0 and ignored by the 584 receiver 586 A 1-bit flag: "Registration for Anycast Address" 588 M 1-bit flag: "Registration for Multicast Address" 590 6.2. New EDAR Message Flag field 592 Section 4 of [RFC6775] provides the same format for DAR and DAC 593 messages by but the status field is only used in DAC message and has 594 to set to zero in DAC messages. [RFC8505] extends the DAC message as 595 an EDAC but does not change the status field in the EDAR. 597 This specification repurposes the status field in the EDAR and a 598 Flags field. It adds a new M flag to the EDAR flags field to signal 599 that the Registered Address is a multicast address and a new A flag 600 to signal that the Registered Address is an anycast address. As for 601 EARO, the flags are mutually exclusive. 603 Figure 5 illustrates the A and M flags in their suggested positions 604 (0 and 1, respectively, counting 0 to 7 in network order in the 8-bit 605 array), to be confirmed by IANA. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type |CodePfx|CodeSfx| Checksum | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |A|M| Reserved | TID | Registration Lifetime | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | | 615 ... Registration Ownership Verifier (ROVR) ... 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | | 619 + + 620 | | 621 + Registered Address + 622 | | 623 + + 624 | | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 5: Extended Duplicate Address Message Format 629 New and updated Option Fields: 631 Reserved 6-bit field: reserved, MUST be set to 0 and ignored by the 632 receiver 634 A 1-bit flag: "Registration for Anycast Address" 636 M 1-bit flag: "Registration for Multicast Address" 638 6.3. Registering Extensions 640 With [RFC8505]: 642 * Only unicast addresses can be registered. 644 * The 6LN must register all its ULA and GUA with a NS(EARO). 646 * The 6LN may set the R flag in the EARO to obtain return 647 reachability services by the 6LR, e.g., through ND proxy 648 operations, or by injecting the route in a route-over subnet. 650 * the 6LR maintains a registration state per Registered Address, 651 including an NCE with the Link Layer Address (LLA) of the 652 Registered Node (the 6LN here). 654 This specification adds the following behavior: 656 * Registration for multicast and anycast addresses is now supported. 657 New flags are added to the EARO to signal when the registered 658 address is anycast or multicast. 660 * The Status field in the EDAR message that was reserved and not 661 used in RFC 8505 is repurposed to transport the flags to signal 662 multicast and anycast. 664 * The 6LN MUST also register all the IPv6 multicast addresses that 665 it listens to but the all_nodes link-scope multicast address 666 FF02::1 [RFC4291] which is implicitly registered, and it MUST set 667 the M flag in the EARO for those addresses. 669 * The 6LN MAY set the R flag in the EARO to obtain the delivery of 670 the multicast packets by the 6LR, e.g., by MLD proxy operations, 671 or by injecting the address in a route-over subnet or in the 672 Protocol Independent Multicast [RFC7761] protocol. 674 * The 6LN MUST also register all the IPv6 anycast addresses that it 675 supports and it MUST set the A flag in the EARO for those 676 addresses. 678 * The 6LR and the 6LBR are extended to accept more than one 679 registration for the same address when it is anycast or multicast, 680 since multiple 6LNs may subscribe to the same address of these 681 types. In both cases, the Registration Ownership Verifier (ROVR) 682 in the EARO identifies uniquely a registration within the 683 namespace of the Registered Address. 685 * The 6LR MUST also consider that all the nodes that registered an 686 address to it (as known by the SLLAO) also registered to the all 687 nodes link-scope multicast address FF02::1 [RFC4291]. 689 * The 6LR MUST maintain a registration state per tuple (IPv6 690 address, ROVR) for both anycast and multicast types of address. 691 It SHOULD notify the 6LBR with an EDAR message, unless it 692 determined that the 6LBR is legacy and does not support this 693 specification. In turn, the 6LBR MUST maintain a registration 694 state per tuple (IPv6 address, ROVR) for both anycast and 695 multicast types of address. 697 7. Updating RFC 9010 699 With [RFC9010]: 701 * The 6LR injects only unicast routes in RPL 703 * Upon a registration with the R flag set to 1 in the EARO, the 6LR 704 injects the address in the RPL unicast support. 706 * Upon receiving a packet directed to a unicast address for which it 707 has an active registration, the 6LR delivers the packet as a 708 unicast layer-2 frame to the LLA the nodes that registered the 709 unicast address. 711 This specification adds the following behavior: 713 * Upon a registration with the R and the M flags set to 1 in the 714 EARO, the 6LR injects the address in the RPL multicast support and 715 sets the M flag in the RTO. 717 * Upon a registration with the R and the A flags set to 1 in the 718 EARO, the 6LR injects the address in the new RPL anycast support 719 and sets the A flag in the RTO. 721 * Upon receiving a packet directed to a multicast address for which 722 it has at least one registration, the 6LR delivers a copy of the 723 packet as a unicast layer-2 frame to the LLA of each of the nodes 724 that registered to that multicast address. 726 * Upon receiving a packet directed to a multicast address for which 727 it has at least one registration, the 6LR delivers a copy of the 728 packet as a unicast layer-2 frame to the LLA of exactly one of the 729 nodes that registered to that multicast address. 731 8. Leveraging RFC 8929 733 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks 734 [RFC8928] was defined to protect the ownership of unicast IPv6 735 addresses that are registered with [RFC8505]. 737 With [RFC8928], it is possible for a node to autoconfigure a pair of 738 public and private keys and use them to sign the registration of 739 addresses that are either autoconfigured or obtained through other 740 methods. 742 The first hop router (the 6LR) may then validate a registration and 743 perform source address validation on packets coming from the sender 744 node (the 6LN). 746 Anycast and multicast addresses are not owned by one node. Multiple 747 nodes may subscribe to the same address. Also, anycast and multicast 748 addresses are not used to source traffic. In that context, the 749 method specified in [RFC8928] cannot be used with autoconfigured 750 keypairs to protect a single ownership. 752 For an anycast or a multicast address, it is still possible to 753 leverage [RFC8928] to enforce the right to subscribe. A keypair MUST 754 be associated with the address before it is deployed, and a ROVR MUST 755 be generated from that keypair as specified in [RFC8928]. The 756 address and the ROVR MUST then be installed in the 6LBR so it can 757 recognize the address and compare the ROVR on the first registration. 759 The keypair MUST then be provisioned in each node that needs to 760 subscribe to the anycast or multicast address, so the node can follow 761 the steps in [RFC8928] to register the address. 763 9. Deployment considerations 765 With this specification, a RPL DODAG forms a realm, and multiple RPL 766 DODAGs may federated in a single RPL Instance administratively. This 767 means that a multicast address that needs to span a RPL DODAG MUST 768 use a scope of Realm-Local whereas a multicast address that needs to 769 span a RPL Instance MUST use a scope of Admin-Local as discussed in 770 section 3 of "IPv6 Multicast Address Scopes" [RFC7346]. 772 "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed 773 IPv4 addresses in IPv6 addresses. The Root of a DODAG may leverage 774 that technique to translate IPv4 traffic in IPv6 and route along the 775 RPL domain. When encapsulating an packet with an IPv4 multicast 776 Destination Address, it MUST use form a multicast address and use the 777 appropriate scope, Realm-Local or Admin-Local. 779 "Unicast-Prefix-based IPv6 Multicast Addresses" [RFC3306] enables to 780 form 2^32 multicast addresses from a single /64 prefix. If an IPv6 781 prefix is associated to an Instance or a RPL DODAG, this provides a 782 namespace that can be used in any desired fashion. It is for 783 instance possible for a standard defining organization to form its 784 own registry and allocate 32-bit values from that namespace to 785 network functions or device types. When used within a RPL deployment 786 that is associated with a /64 prefix the IPv6 multicast addresses can 787 be automatically derived from the prefix and the 32-bit value for 788 either a Realm-Local or an Admin-Local multicast address as needed in 789 the configuration. 791 IN a "green field" deployment where all nodes support this 792 specification, it is possible to deploy a single RPL Instance using a 793 multicast MOP for unicast, multicast and anycast addresses. 795 In a "brown field" where legacy devices that do not support this 796 specification co-exist with upgraded devices, it is RECOMMENDED to 797 deploy one RPL Instance in any Mode of Operation (typically MOP 1) 798 for unicast that legacy nodes can join, and a separate RPL Instance 799 dedicated to multicast and anycast operations using a multicast MOP. 801 To deploy a Storing Mode multicast operation using MOP 3 in a RPL 802 domain, it is required that there is enough density of RPL routers 803 that support MOP 3 to build a DODAG that covers all the potential 804 listeners and include the spanning multicast trees that are needed to 805 distribute the multicast flows. This might not be the case when 806 extending the capabilities of an existing network. 808 In the case of the new Non-Storing multicast MOP, arguably the new 809 support is only needed at the 6LRs that will accept multicast 810 listeners. It is still required that each listener can reach at 811 least one such 6LR, so the upgraded 6LRs must be deployed to cover 812 all the 6LN that need multicast services. 814 Using separate RPL Instances for in the one hand unicast traffic and 815 in the other hand anycast and multicast traffic allows to use 816 different objective function, one favoring the link quality up for 817 unicast collection and one favoring downwards link quality for 818 multicast distribution. 820 But this might be impractical in some use cases where the signaling 821 and the state to be installed in the devices are very constrained, 822 the upgraded devices are too sparse, or the devices do not support 823 more multiple instances. 825 When using a single RPL Instance, MOP 3 expects the Storing Mode of 826 Operation for both unicast and multicast, which is an issue in 827 constrained networks that typically use MOP 1 for unicast. This 828 specification allows a mixed mode that is signaled as MOP 1 in the 829 DIO messages for backward compatibility, where limited multicast and/ 830 or anycast is available, under the following conditions: 832 * There MUST be enough density of 6LRs that support the mixed mode 833 to cover the all the 6LNs that require multicast or anycast 834 services. In Storing Mode, there MUST be enough density or 6LR 835 that support the mixed mode to also form a DODAG to the Root. 837 * The RPL routers that support the mixed mode and are configured to 838 operate in in accordance with the desired operation in the 839 network. 841 * The MOP signaled in the RPL DODAG Information Object (DIO) 842 messages is MOP 1 to enable the legacy nodes to operate as leaves. 844 * The support of multicast and/or anycast in the RPL Instance SHOULD 845 be signaled by the 6LRs to the 6LN using a 6CIO, see Section 4. 847 * Alternatively, the support of multicast in the RPL domain can be 848 globally known by other means such as configuration or external 849 information such as support of a version of an industry standard 850 that mandates it. In that case, all the routers MUST support the 851 mixed mode. 853 10. Security Considerations 855 This specification extends [RFC8505], and the security section of 856 that document also applies to this document. In particular, the link 857 layer SHOULD be sufficiently protected to prevent rogue access. 859 Section 8 leverages [RFC8928] to prevent an unwanted subscriber to 860 register for an anycast of a multicast address. This mechanism comes 861 with a keypair that is shared between all subscribers. A shared key 862 is prone to be stolen and the level of protection can only go down 863 with time. 865 It is possible to update the keys associated to an address in all the 866 6LNs, but the flow is not clearly documented and may not complete in 867 due time for all nodes in LLN use cases. It may be simpler to 868 install a all-new address with new keys over a period of time, and 869 switch the traffic to that address when the migreaiton is complete. 871 11. Backward Compatibility 873 A legacy 6LN will not register multicast addresses and the service 874 will be the same when the network is upgraded. A legacy 6LR will not 875 set the M flag in the 6CIO and an upgraded 6LN will not register 876 multicast addresses. 878 Upon an EDAR message, a legacy 6LBR may not realize that the address 879 being registered is anycast or multicast, and return that it is 880 duplicate in the EDAC status. The 6LR MUST ignore a duplicate status 881 in the EDAR for anycast and multicast addresses. 883 As detailed in Section 9, it is possible to add multicast on an 884 existing MOP 1 deployment. 886 The combination of a multicast address and the M flag set to 0 in an 887 RTO in a MOP 3 RPL Instance is understood by the receiver that 888 supports this specification (the parent) as an indication that the 889 sender (child) does not support this specification, but the RTO is 890 accepted and processed as if the M flag was set for backward 891 compatibility. 893 When the DODAG is operated in MOP 3, a legacy node will not set the M 894 flag and still expect multicast service as specified in section 12 of 895 [RFC6550]. In MOP 3 an RTO that is received with a target that is 896 multicast and the M bit set to 0 MUST be considered as multicast and 897 MUST be processed as if the M flag is set. 899 12. IANA Considerations 901 Note to RFC Editor, to be removed: please replace "This RFC" 902 throughout this document by the RFC number for this specification 903 once it is allocated. Also, the I Field is defined in [RFC9010] but 904 is missing from the subregistry, so the bit positions must be added 905 for completeness. 907 IANA is requested to make changes under the "Internet Control Message 908 Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing 909 Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] 910 registries, as follows: 912 12.1. New EDAR Message Flags Subregistry 914 IANA is requested to create a new "EDAR Message Flags" subregistry of 915 the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" 916 registry as indicated in Table 1: 918 +---------------+---------------------------------------+-----------+ 919 | Bit Number | Meaning | Reference | 920 +---------------+---------------------------------------+-----------+ 921 | 0 (suggested) | A flag: Registered | This RFC | 922 | | Address is Anycast | | 923 +---------------+---------------------------------------+-----------+ 924 | 1 (suggested) | M flag: Registered | This RFC | 925 | | Address is Multicast | | 926 +---------------+---------------------------------------+-----------+ 928 Table 1: EDAR Message flags 930 12.2. New EARO flags 932 IANA is requested to make additions to the "Address Registration 933 Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message 934 Protocol version 6 (ICMPv6) Parameters" registry as indicated in 935 Table 2: 937 +---------------+-----------------------+-----------+ 938 | ARO flag | Meaning | Reference | 939 +---------------+-----------------------+-----------+ 940 | 2 (suggested) | A flag: Registration | This RFC | 941 | | for Anycast Address | | 942 +---------------+-----------------------+-----------+ 943 | 3 (suggested) | M flag: Registration | This RFC | 944 | | for Multicast Address | | 945 +---------------+-----------------------+-----------+ 946 | 4 and 5 | "I" Field | RFC 8505 | 947 +---------------+-----------------------+-----------+ 949 Table 2: New ARO flags 951 12.3. New RTO flags 953 IANA is requested to make additions to the "RPL Target Option Flags" 954 [IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power 955 and Lossy Networks (RPL)" registry as indicated in Table 3: 957 +---------------+---------------------------------------+-----------+ 958 | Bit Number | Meaning | Reference | 959 +---------------+---------------------------------------+-----------+ 960 | 2 (suggested) | A flag: Registered | This RFC | 961 | | Address is Anycast | | 962 +---------------+---------------------------------------+-----------+ 963 | 3 (suggested) | M flag: Registered | This RFC | 964 | | Address is Multicast | | 965 +---------------+---------------------------------------+-----------+ 967 Table 3: New RTO flags 969 12.4. New RPL Mode of Operation 971 IANA is requested to make an addition to the "Mode of Operation" 972 [IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and 973 Lossy Networks (RPL)" registry as indicated in Table 4: 975 +---------------+-------------------------------+-----------+ 976 | Value | Description | Reference | 977 +---------------+-------------------------------+-----------+ 978 | 5 (suggested) | Non-Storing Mode of Operation | This RFC | 979 | | with multicast support | | 980 +---------------+-------------------------------+-----------+ 982 Table 4: New RPL Mode of Operation 984 12.5. New 6LoWPAN Capability Bits 986 IANA is requested to make an addition to the "6LoWPAN Capability 987 Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet 988 Control Message Protocol version 6 (ICMPv6) Parameters" registry as 989 indicated in Table 5: 991 +----------------+------------------------------------+-----------+ 992 | Capability Bit | Meaning | Reference | 993 +----------------+------------------------------------+-----------+ 994 | 8 (suggested) | M flag: Registration for Multicast | This RFC | 995 | | and Anycast Addresses Supported | | 996 +----------------+------------------------------------+-----------+ 998 Table 5: New 6LoWPAN Capability Bits 1000 13. Acknowledgments 1002 14. Normative References 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, 1006 DOI 10.17487/RFC2119, March 1997, 1007 . 1009 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1010 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1011 August 2002, . 1013 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1014 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1015 2006, . 1017 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1018 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1019 DOI 10.17487/RFC4861, September 2007, 1020 . 1022 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1023 Address Autoconfiguration", RFC 4862, 1024 DOI 10.17487/RFC4862, September 2007, 1025 . 1027 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1028 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1029 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1030 Low-Power and Lossy Networks", RFC 6550, 1031 DOI 10.17487/RFC6550, March 2012, 1032 . 1034 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1035 Bormann, "Neighbor Discovery Optimization for IPv6 over 1036 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1037 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1038 . 1040 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1041 DOI 10.17487/RFC7346, August 2014, 1042 . 1044 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1045 IPv6 over Low-Power Wireless Personal Area Networks 1046 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1047 2014, . 1049 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1050 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1051 May 2017, . 1053 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1054 (IPv6) Specification", STD 86, RFC 8200, 1055 DOI 10.17487/RFC8200, July 2017, 1056 . 1058 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1059 Perkins, "Registration Extensions for IPv6 over Low-Power 1060 Wireless Personal Area Network (6LoWPAN) Neighbor 1061 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1062 . 1064 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 1065 "Address-Protected Neighbor Discovery for Low-Power and 1066 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 1067 2020, . 1069 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1070 (Routing Protocol for Low-Power and Lossy Networks) 1071 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1072 . 1074 [IANA.ICMP] 1075 IANA, "IANA Registry for ICMPv6", IANA, 1076 https://www.iana.org/assignments/icmpv6-parameters/ 1077 icmpv6-parameters.xhtml. 1079 [IANA.ICMP.ARO.FLG] 1080 IANA, "IANA Sub-Registry for the ARO Flags", IANA, 1081 https://www.iana.org/assignments/icmpv6-parameters/ 1082 icmpv6-parameters.xhtml#icmpv6-adress-registration-option- 1083 flags. 1085 [IANA.ICMP.6CIO] 1086 IANA, "IANA Sub-Registry for the 6LoWPAN Capability Bits", 1087 IANA, https://www.iana.org/assignments/icmpv6-parameters/ 1088 icmpv6-parameters.xhtml#sixlowpan-capability-bits. 1090 [IANA.RPL] IANA, "IANA Registry for the RPL", 1091 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml. 1093 [IANA.RPL.RTO.FLG] 1094 IANA, "IANA Sub-Registry for the RTO Flags", IANA, 1095 https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target- 1096 option-flags. 1098 [IANA.RPL.MOP] 1099 IANA, "IANA Sub-Registry for the RPL Mode of Operation", 1100 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml#mop. 1102 15. Informative References 1104 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1105 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1106 DOI 10.17487/RFC3810, June 2004, 1107 . 1109 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1110 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1111 Overview, Assumptions, Problem Statement, and Goals", 1112 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1113 . 1115 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1116 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1117 DOI 10.17487/RFC6282, September 2011, 1118 . 1120 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1121 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1122 February 2016, . 1124 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1125 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1126 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1127 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1128 2016, . 1130 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1131 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1132 DOI 10.17487/RFC6052, October 2010, 1133 . 1135 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 1136 Option Type, Routing Header for Source Routes, and IPv6- 1137 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1138 DOI 10.17487/RFC9008, April 2021, 1139 . 1141 [Wi-SUN] Heile, B., (Remy), B. L., Zhang, M., and C. E. Perkins, 1142 "Wi-SUN FAN Overview", Work in Progress, Internet-Draft, 1143 draft-heile-lpwan-wisun-overview-00, 3 July 2017, 1144 . 1147 [IEEE Std 802.15.4] 1148 IEEE standard for Information Technology, "IEEE Std 1149 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1150 and Physical Layer (PHY) Specifications for Low-Rate 1151 Wireless Personal Area Networks". 1153 [IEEE Std 802.11] 1154 IEEE standard for Information Technology, "IEEE Standard 1155 802.11 - IEEE Standard for Information Technology - 1156 Telecommunications and information exchange between 1157 systems Local and metropolitan area networks - Specific 1158 requirements - Part 11: Wireless LAN Medium Access Control 1159 (MAC) and Physical Layer (PHY) Specifications.", 1160 . 1162 [IEEE Std 802.15.1] 1163 IEEE standard for Information Technology, "IEEE Standard 1164 for Information Technology - Telecommunications and 1165 Information Exchange Between Systems - Local and 1166 Metropolitan Area Networks - Specific Requirements. - Part 1167 15.1: Wireless Medium Access Control (MAC) and Physical 1168 Layer (PHY) Specifications for Wireless Personal Area 1169 Networks (WPANs)". 1171 Author's Address 1173 Pascal Thubert (editor) 1174 Cisco Systems, Inc 1175 Building D 1176 45 Allee des Ormes - BP1200 1177 06254 Mougins - Sophia Antipolis 1178 France 1179 Phone: +33 497 23 26 34 1180 Email: pthubert@cisco.com