idnits 2.17.00 (12 Aug 2021) /tmp/idnits9082/draft-ietf-6lo-multicast-registration-02.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 November 2021) is 194 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 (~~), 1 warning (==), 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) 8 November 2021 5 Intended status: Standards Track 6 Expires: 12 May 2022 8 IPv6 Neighbor Discovery Multicast Address Listener Registration 9 draft-ietf-6lo-multicast-registration-02 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 12 May 2022. 37 Copyright Notice 39 Copyright (c) 2021 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 Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified 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. Deployment considerations . . . . . . . . . . . . . . . . . . 17 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 74 11.1. New EDAR Message Flags Subregistry . . . . . . . . . . . 20 75 11.2. New EARO flags . . . . . . . . . . . . . . . . . . . . . 20 76 11.3. New RTO flags . . . . . . . . . . . . . . . . . . . . . 20 77 11.4. New RPL Mode of Operation . . . . . . . . . . . . . . . 21 78 11.5. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 21 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 80 13. Normative References . . . . . . . . . . . . . . . . . . . . 21 81 14. Informative References . . . . . . . . . . . . . . . . . . . 23 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 84 1. Introduction 86 The design of Low Power and Lossy Networks (LLNs) is generally 87 focused on saving energy, which is the most constrained resource of 88 all. Other design constraints, such as a limited memory capacity, 89 duty cycling of the LLN devices and low-power lossy transmissions, 90 derive from that primary concern. The radio (both transmitting or 91 simply listening) is a major energy drain and the LLN protocols must 92 be adapted to allow the nodes to remain sleeping with the radio 93 turned off at most times. 95 The "Routing Protocol for Low Power and Lossy Networks" [RFC6550] 96 (RPL) to provide IPv6 [RFC8200] routing services within such 97 constraints. To save signaling and routing state in constrained 98 networks, the RPL routing is only performed along a Destination- 99 Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a 100 Root node, as opposed to along the shortest path between 2 peers, 101 whatever that would mean in each LLN. 103 This trades the quality of peer-to-peer (P2P) paths for a vastly 104 reduced amount of control traffic and routing state that would be 105 required to operate an any-to-any shortest path protocol. 106 Additionally, broken routes may be fixed lazily and on-demand, based 107 on dataplane inconsistency discovery, which avoids wasting energy in 108 the proactive repair of unused paths. 110 Section 12 of [RFC6550] details the "Storing Mode of Operation with 111 multicast support" with source-independent multicast routing in RPL. 113 The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] 114 [RFC4862] was defined for serial links and shared transit media such 115 as Ethernet at a time when broadcast was cheap on those media while 116 memory for neighbor cache was expensive. It was thus designed as a 117 reactive protocol that relies on caching and multicast operations for 118 the Address Discovery (aka Lookup) and Duplicate Address Detection 119 (DAD) of IPv6 unicast addresses. Those multicast operations 120 typically impact every node on-link when at most one is really 121 targeted, which is a waste of energy, and imply that all nodes are 122 awake to hear the request, which is inconsistent with power saving 123 (sleeping) modes. 125 The original 6LoWPAN ND, "Neighbor Discovery Optimizations for 126 6LoWPAN networks" [RFC6775], was introduced to avoid the excessive 127 use of multicast messages and enable IPv6 ND for operations over 128 energy-constrained nodes. [RFC6775] changes the classical IPv6 ND 129 model to proactively establish the Neighbor Cache Entry (NCE) 130 associated to the unicast address of a 6LoWPAN Node (6LN) in the a 131 6LoWPAN Router(s) (6LR) that serves it. To that effect, [RFC6775] 132 defines a new Address Registration Option (ARO) that is placed in 133 unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) 134 messages between the 6LN and the 6LR. 136 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 137 updates [RFC6775] into a generic Address Registration mechanism that 138 can be used to access services such as routing and ND proxy and 139 introduces the Extended Address Registration Option (EARO) for that 140 purpose. This provides a routing-agnostic interface for a host to 141 request that the router injects a unicast IPv6 address in the local 142 routing protocol and provide return reachability for that address. 144 "Routing for RPL Leaves" [RFC9010] provides the router counterpart of 145 the mechanism for a host that implements [RFC8505] to inject its 146 unicast Unique Local Addresses (ULAs) and Global Unicast Addresses 147 (GUAs) in RPL. But though RPL also provides multicast routing, 148 6LoWPAN ND supports only the registration of unicast addresses and 149 there is no equivalent of [RFC9010] to specify the 6LR behavior upon 150 the registration of one or more multicast address. 152 The "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" 153 [RFC3810] enables the router to learn which node listens to which 154 multicast address, but as the classical IPv6 ND protocol, MLD relies 155 on multicasting Queries to all nodes, which is unfit for low power 156 operations. As for IPv6 ND, it makes sense to let the 6LNs control 157 when and how they maintain the state associated to their multicast 158 addresses in the 6LR, e.g., during their own wake time. In the case 159 of a constrained node that already implements [RFC8505] for unicast 160 reachability, it makes sense to extend to that support to register 161 the multicast addresses they listen to. 163 This specification extends [RFC8505] and [RFC9010] to add the 164 capability for the 6LN to register anycast and multicast addresses 165 and for the 6LR to inject them in RPL. 167 2. Terminology 169 2.1. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 2.2. References 179 This document uses terms and concepts that are discussed in: 181 * "Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 182 Stateless address Autoconfiguration" [RFC4862], 184 * Neighbor Discovery Optimization for Low-Power and Lossy Networks 185 [RFC6775], as well as 187 * "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 188 and 190 * "Using RPI Option Type, Routing Header for Source Routes, and 191 IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008]. 193 2.3. Glossary 195 This document uses the following acronyms: 197 6BBR 6LoWPAN Backbone Router 198 6BBR 6LoWPAN Border Router 199 6LN 6LoWPAN Node 200 6LR 6LoWPAN Router 201 6CIO Capability Indication Option 202 AMC Address Mapping Confirmation 203 AMR Address Mapping Request 204 ARO Address Registration Option 205 DAC Duplicate Address Confirmation 206 DAD Duplicate Address Detection 207 DAR Duplicate Address Request 208 EARO Extended Address Registration Option 209 EDAC Extended Duplicate Address Confirmation 210 EDAR Extended Duplicate Address Request 211 DODAG Destination-Oriented Directed Acyclic Graph 212 IR Ingress Replication 213 LLN Low-Power and Lossy Network 214 NA Neighbor Advertisement 215 NCE Neighbor Cache Entry 216 ND Neighbor Discovery 217 NS Neighbor Solicitation 218 ROVR Registration Ownership Verifier 219 RTO RPL Target Option 220 RA Router Advertisement 221 RS Router Solicitation 222 TID Transaction ID 223 TIO Transit Information Option 225 3. Overview 227 This specification inherits from [RFC6550], [RFC8505], and [RFC8505] 228 to provide additional capabilities for anycast and multicast. Unless 229 specified otherwise therein, the behavior of the 6LBR that acts as 230 RPL Root, of the intermediate routers down the RPL graph, of the 6LR 231 that act as access routers and of the 6LNs that are the RFC-unaware 232 destinations, is the same as for unicast. In particular, forwarding 233 a packet happens as specified in section 11 of [RFC6550], including 234 loop avoidance and detection, though in the case of multicast 235 multiple copies might be generated. 237 [RFC8505] is a pre-requisite to this specification. A node that 238 implements this MUST also implement [RFC8505]. This specification 239 does not introduce a new option; it modifies existing options and 240 updates the associated behaviors to enable the Registration for 241 Multicast Addresses as an extension to [RFC8505]. 243 This specification also extends [RFC6550] and [RFC9010] in the case 244 of a route-over multilink subnet based on the RPL routing protocol, 245 to add multicast ingress replication in Non-Storing Mode and anycast 246 support in both Storing and Non-Storing modes. A 6LR that implements 247 the RPL extensions specified therein MUST also implement [RFC9010]. 249 Figure 1 illustrates the classical situation of an LLN as a single 250 IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root 251 for RPL operations and maintains a registry of the active 252 registrations as an abstract data structure called an Address 253 Registrar for 6LoWPAN ND. 255 The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi 256 [IEEE Std 802.11] and Bluetooth (Low Energy) [IEEE Std 802.15.1], or 257 a Route-Over LLN such as the Wi-SUN mesh [Wi-SUN] that leverages 258 6LoWPAN [RFC4919][RFC6282] and RPL [RFC6550] over [IEEE Std 259 802.15.4]. 261 | 262 ----+-------+------------ 263 | Wire side 264 +------+ 265 | 6LBR | 266 |(Root)| 267 +------+ 268 o o o Wireless side 269 o o o o o o 270 o o o o o o o 271 o o o LLN o +---+ 272 o o o o o |6LR| 273 o o o o o +---+ 274 o o o o o o z 275 o o oo o o +---+ 276 o |6LN| 277 +---+ 279 Figure 1: Wireless Mesh 281 A leaf acting as a 6LN registers its unicast and anycast addresses a 282 RPL router acting as a 6LR, using a layer-2 unicast NS message with 283 an EARO as specified in [RFC8505]. The registration state is 284 periodically renewed by the Registering Node, before the lifetime 285 indicated in the EARO expires. As for unicast IPv6 addresses, the 286 6LR uses an EDAR/EDAR exchange with the 6LBR to notify the 6LBR of 287 the presence of the listeners. 289 With this specification, the 6LNs can now subscribe to the multicast 290 addresses they listen to, using a new M flag in the EARO to signal 291 that the registration is for a multicast address. Multiple 6LN may 292 subscribe to the same multicast address to the same 6LR. Note the 293 use of the term "subscribe": using the EARO registration mechanism, a 294 node registers the unicast addresses that it owns, but subscribes to 295 the multicast addresses that it listens to. 297 With this specification, the 6LNs can also register the anycast 298 addresses they accept, using a new A flag in the EARO to signal that 299 the registration is for an anycast address. As for multicast, 300 multiple 6LN may register the same anycast address to the same 6LR. 302 If the R flag is set in the registration of one or more 6LNs for the 303 same address, the 6LR injects the anycast and multicast addresses in 304 RPL, based on the longest registration lifetime across the active 305 registrations for the address. 307 In the RPL "Storing Mode of Operation with multicast support", the 308 DAO messages for the multicast address percolate along the RPL 309 preferred parent tree and mark a subtree that becomes the multicast 310 tree for that multicast address, with 6LNs that subscribed to the 311 address as the leaves. As prescribed in section 12 of [RFC6550], the 312 6LR forwards a multicast packet as an individual unicast MAC frame to 313 each peer along the multicast tree, excepting to the node it received 314 the packet from. 316 In the new RPL "Non-Storing Mode of Operation with multicast support" 317 that is introduced here, the DAO messages announce the multicast 318 addresses as Targets though never as Transit. The multicast 319 distribution is an ingress replication whereby the Root encapsulates 320 the multicast packets to all the 6LRs that are transit for the 321 multicast address, using the same source-routing header as for 322 unicast targets attached to the respective 6LRs. 324 Broadcasting is typically unreliable in LLNs (no ack) and forces a 325 listener to remain awake, so it generally discouraged. The 326 expectation is thus that in either mode, the 6LRs deliver the 327 multicast packets as individual unicast MAC frames to each of the 328 6LNs that subscribed to the multicast address. 330 With this specification, anycast addresses can be injected in RPL in 331 both Storing and Non-Storing modes. In Storing Mode the RPL router 332 accepts DAO from multiple children for the same anycast address, but 333 only forwards a packet to one of the children. In Non-Storing Mode, 334 the Root maintains the list of all the RPL nodes that announced the 335 anycast address as Target, but forwards a given packet to only one of 336 them. 338 For backward compatibility, this specification allows to build a 339 single DODAG signaled as MOP 1, that conveys anycast, unicast and 340 multicast packets using the same source routing mechanism, more in 341 Section 8. 343 It is also possible to leverage this specification between the 6LN 344 and the 6LR for the registration of unicast, anycast and multicast 345 IPv6 addresses in networks that are not necessarily LLNs, and/or 346 where the routing protocol between the 6LR and above is not 347 necessarily RPL. In that case, the distribution of packets between 348 the 6LR and the 6LNs may effectively rely on a broadcast or multicast 349 support at the lower layer. 351 For instance, it is possible to operate a RPL Instance in the new 352 "Non-Storing Mode of Operation with multicast support" (while 353 possibly signaling a MOP of 1) and use "Multicast Protocol for 354 Low-Power and Lossy Networks (MPL)" [RFC7731] for the multicast 355 operation. MPL floods the DODAG with the multicast messages 356 independently of the RPL DODAG topologies. Two variations are 357 possible: 359 * In one possible variation, all the 6LNs set the R flag in the EARO 360 for a multicast target, upon which the 6LRs send a unicast DAO 361 message to the Root; the Root filters out the multicast messages 362 for which there is no listener and only floods when there is. 364 * In a simpler variation, the 6LNs do not set the R flag and the 365 Root floods all the multicast packets over the whole DODAG. Using 366 configuration, it is also possible to control the behavior of the 367 6LR to ignore the R flag and either always or never send the DAO 368 message, and/or to control the Root and specify which groups it 369 should flood or not flood. 371 Note that if the configuration instructs the 6LR not to send the DAO, 372 then MPL can really by used in conjunction with RPL Storing Mode as 373 well. 375 4. Extending RFC 7400 377 This specification defines a new capability bit for use in the 6CIO 378 as defined by "6LoWPAN-GHC: Generic Header Compression for IPv6 over 379 Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] and 380 extended in [RFC8505] for use in IPv6 ND messages. 382 The new "Registration for Multicast Address Supported" (M) flag 383 indicates to the 6LN that the 6LR accepts multicast address 384 registrations as specified in this document and will ensure that 385 packets for the multicast Registered Address will be routed to the 386 6LNs that registered with the R flag set. 388 Figure 2 illustrates the M flag in its suggested position (8, 389 counting 0 to 15 in network order in the 16-bit array), to be 390 confirmed by IANA. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type | Length = 1 | Reserved |M|A|D|L|B|P|E|G| 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Reserved | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 2: New Capability Bits in the 6CIO 402 New Option Field: 404 M 1-bit flag: "Registration for Multicast and Anycast Addresses 405 Supported" 407 5. Updating RFC 6550 409 5.1. Updating MOP 3 411 RPL supports multicast operations in the "Storing Mode of Operation 412 with multicast support" (MOP 3) which provides source-independent 413 multicast routing in RPL, as prescribed in section 12 of [RFC6550]. 414 MOP 3 is a storing Mode of Operation. This operation builds a 415 multicast tree within the RPL DODAG for each multicast address. This 416 specification provides additional details for the MOP 3 operation. 418 The expectation in MOP 3 is that the unicast traffic also follows the 419 Storing Mode of Operation. But this is rarely the case in LLN 420 deployments of RPL where the "Non-Storing Mode of Operation" (MOP 1) 421 is the norm. Though it is preferred to build separate RPL Instances, 422 one in MOP 1 and one in MOP 3, this specification allows to hybrid 423 the Storing Mode for multicast and Non-Storing Mode for unicast in 424 the same RPL Instance, more in Section 8. 426 5.2. New Non-Storing Multicast MOP 428 This specification adds a "Non-Storing Mode of Operation with 429 multicast support" (MOP to be assigned by IANA) whereby the non- 430 storing Mode DAO to the Root may contain multicast addresses in the 431 RPL Target Option (RTO), whereas the Transit Information Option (TIO) 432 cannot. 434 In that mode, the RPL Root performs an ingress replication (IR) 435 operation on the multicast packets, meaning that it transmits one 436 copy of each multicast packet to each 6LR that is a transit for the 437 multicast target, using the same source routing header and 438 encapsulation as it would for a unicast packet for a RPL Unaware Leaf 439 (RUL) attached to that 6LR. 441 For the intermediate routers, the packet appears as any source routed 442 unicast packet. The difference shows only at the 6LR, that 443 terminates the source routed path and forwards the multicast packet 444 to all 6LNs that registered for the multicast address. 446 For a packet that is generated by the Root, this means that the Root 447 builds a source routing header as shown in section 8.1.3 of 448 [RFC9008], but for which the last and only the last address is 449 multicast. For a packet that is not generated by the Root, the Root 450 encapsulates the multicast packet as per section 8.2.4 of [RFC9008]. 451 In that case, the outer header is purely unicast, and the 452 encapsulated packet is purely multicast. 454 For this new mode as well, this specification allows to enable the 455 operation in a MOP 1 brown field, more in Section 8. 457 5.3. RPL Anycast Operation 459 With multicast, the address has a recognizable format, and a 460 multicast packet is to be delivered to all the active subscribers. 461 In contrast with anycast, the format of the address is not 462 distinguishable from that of unicast. A legacy node may issue a DAO 463 message without setting the A flag, the unicast behaviour may apply 464 to anycast traffic in a subDAGs. A target is routed as anycast by a 465 parent (or the Root) that received at least one DAO message for that 466 target with the A flag set to 1. As for multicast, the freshness 467 comparison cannot apply to an anycast target, and the TID field is 468 ignored. 470 As opposed to multicast, the anycast operation described therein 471 applies to both addresses and prefixes, and the A flag can be set for 472 both. An external destination (address or prefix) that may be 473 injected as a RPL target from multiple border routers SHOULD be 474 injected as anycast in RPL to enable load balancing. A mobile target 475 that is multihomed SHOULD in contrast be advertised as unicast over 476 the multiple interfaces to favor the TID comparision and vs. the 477 multipath load balancing. 479 For either multicast and anycast, there can be multiple registrations 480 from multiple parties, each using a different value of the ROVR field 481 that identifies the individual registration. The 6LR MUST maintain a 482 registration state per value of the ROVR per multicast or anycast 483 address, but inject the route into RPL only once for each address. 484 Since the registrations are considered separate, the check on the TID 485 that acts as registration sequence only applies to the registration 486 with the same ROVR. 488 The 6LRs that inject multicast and anycast routes into RPL may not be 489 synchronized to advertise same value of the Path Sequence in the RPL 490 TIO. It results that the value the Path Sequence is irrelevant when 491 the target is anycast or multicast, and that it MUST be ignored. 493 Like the 6LR, a RPL router in Storing Mode propagates the route to 494 its parent(s) in DAO messages once and only once for each address, 495 but it MUST retain a routing table entry for each of the children 496 that advertised the address. 498 When forwarding multicast packets down the DODAG, the RPL router 499 copies all the children that advertised the address in their DAO 500 messages. In contrast, when forwarding anycast packets down the 501 DODAG, the RPL router MUST copy one and only one of the children that 502 advertised the address in their DAO messages, and forward to one 503 parent if there is no such child. 505 5.4. New RPL Target Option Flags 507 [RFC6550] recognizes a multicast address by its format (as specified 508 in section 2.7 of [RFC4291]) and applies the specified multicast 509 operation if the address is recognized as multicast. This 510 specification updates [RFC6550] to add the M and A flags to the RTO 511 to indicate that the target address is to be processed as multicast 512 or anycast, respectively. 514 An RTO that has the M flag set to 1 is called a multicast RTO. An 515 RTO that has the A flag set to 1 is called an anycast RTO. An RTO 516 that has both the A and the M flags set to 0 is called an unicast 517 RTO. With this specification, the M and A flags are mutually 518 exclusive and MUST NOT be both set to 1. The capability to set both 519 flags is reserved and an RTO that is received with both flags set 520 MUST be ignored. 522 The suggested position for the A and M flags are 2 and 3 counting 523 from 0 to 7 in network order as shown in Figure 3, based on figure 4 524 of [RFC9010] which defines the flags in position 0 and 1: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type = 0x05 | Option Length |F|X|A|M|ROVRsz | Prefix Length | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 | Target Prefix (Variable Length) | 533 . . 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 ... Registration Ownership Verifier (ROVR) ... 537 | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Figure 3: Format of the RPL Target Option 542 6. Updating RFC 8505 543 6.1. New EARO flag 545 Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO 546 option defined in [RFC6775]. 548 This specification adds a new M flag to the EARO flags field to 549 signal that the Registered Address is a multicast address. When both 550 the M and the R flags are set, the 6LR that conforms to this 551 specification joins the multicast stream, e.g., by injecting the 552 address in the RPL multicast support which is extended in this 553 specification for Non-Storing Mode. 555 This specification adds a new A flag to the EARO flags field to 556 signal that the Registered Address is an anycast address. When both 557 the A and the R flags are set, the 6LR that conforms to this 558 specification injects the anycast address in the RPL anycast support 559 that is introduced in this specification for both Storing and Non- 560 Storing Modes. 562 Figure 4 illustrates the A and M flags in their suggested positions 563 (2 and 3, respectively, counting 0 to 7 in network order in the 8-bit 564 array), to be confirmed by IANA. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | Status | Opaque | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 |Rsv|A|M| I |R|T| TID | Registration Lifetime | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 ... Registration Ownership Verifier ... 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 4: EARO Option Format 580 New and updated Option Fields: 582 Rsv 2-bit field: reserved, MUST be set to 0 and ignored by the 583 receiver 585 A 1-bit flag: "Registration for Anycast Address" 587 M 1-bit flag: "Registration for Multicast Address" 589 6.2. New EDAR Message Flag field 591 Section 4 of [RFC6775] provides the same format for DAR and DAC 592 messages by but the status field is only used in DAC message and has 593 to set to zero in DAC messages. [RFC8505] extends the DAC message as 594 an EDAC but does not change the status field in the EDAR. 596 This specification repurposes the status field in the EDAR and a 597 Flags field. It adds a new M flag to the EDAR flags field to signal 598 that the Registered Address is a multicast address and a new A flag 599 to signal that the Registered Address is an anycast address. As for 600 EARO, the flags are mutually exclusive. 602 Figure 5 illustrates the A and M flags in their suggested positions 603 (0 and 1, respectively, counting 0 to 7 in network order in the 8-bit 604 array), to be confirmed by IANA. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type |CodePfx|CodeSfx| Checksum | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 |A|M| Reserved | TID | Registration Lifetime | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 ... Registration Ownership Verifier (ROVR) ... 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | | 618 + + 619 | | 620 + Registered Address + 621 | | 622 + + 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Figure 5: Extended Duplicate Address Message Format 628 New and updated Option Fields: 630 Reserved 6-bit field: reserved, MUST be set to 0 and ignored by the 631 receiver 633 A 1-bit flag: "Registration for Anycast Address" 635 M 1-bit flag: "Registration for Multicast Address" 637 6.3. Registering Extensions 639 With [RFC8505]: 641 * Only unicast addresses can be registered. 643 * The 6LN must register all its ULA and GUA with a NS(EARO). 645 * The 6LN may set the R flag in the EARO to obtain return 646 reachability services by the 6LR, e.g., through ND proxy 647 operations, or by injecting the route in a route-over subnet. 649 * the 6LR maintains a registration state per Registered Address, 650 including an NCE with the Link Layer Address (LLA) of the 651 Registered Node (the 6LN here). 653 This specification adds the following behavior: 655 * Registration for multicast and anycast addresses is now supported. 656 New flags are added to the EARO to signal when the registered 657 address is anycast or multicast. 659 * The Status field in the EDAR message that was reserved and not 660 used in RFC 8505 is repurposed to transport the flags to signal 661 multicast and anycast. 663 * The 6LN MUST also register all the IPv6 multicast addresses that 664 it listens to and it MUST set the M flag in the EARO for those 665 addresses. 667 * The 6LN MAY set the R flag in the EARO to obtain the delivery of 668 the multicast packets by the 6LR, e.g., by MLD proxy operations, 669 or by injecting the address in a route-over subnet or in the 670 Protocol Independent Multicast [RFC7761] protocol. 672 * The 6LN MUST also register all the IPv6 anycast addresses that it 673 supports and it MUST set the A flag in the EARO for those 674 addresses. 676 * The 6LR and the 6LBR are extended to accept more than one 677 registration for the same address when it is anycast or multicast, 678 since multiple 6LNs may subscribe to the same address of these 679 types. In both cases, the Registration Ownership Verifier (ROVR) 680 in the EARO identifies uniquely a registration within the 681 namespace of the Registered Address. 683 * The 6LR MUST maintain a registration state per tuple (IPv6 684 address, ROVR) for both anycast and multicast types of address. 685 It SHOULD notify the 6LBR with an EDAR message, unless it 686 determined that the 6LBR is legacy and does not support this 687 specification. In turn, the 6LBR MUST maintain a registration 688 state per tuple (IPv6 address, ROVR) for both anycast and 689 multicast types of address. 691 7. Updating RFC 9010 693 With [RFC9010]: 695 * The 6LR injects only unicast routes in RPL 697 * Upon a registration with the R flag set to 1 in the EARO, the 6LR 698 injects the address in the RPL unicast support. 700 * Upon receiving a packet directed to a unicast address for which it 701 has an active registration, the 6LR delivers the packet as a 702 unicast layer-2 frame to the LLA the nodes that registered the 703 unicast address. 705 This specification adds the following behavior: 707 * Upon a registration with the R and the M flags set to 1 in the 708 EARO, the 6LR injects the address in the RPL multicast support and 709 sets the M flag in the RTO. 711 * Upon a registration with the R and the A flags set to 1 in the 712 EARO, the 6LR injects the address in the new RPL anycast support 713 and sets the A flag in the RTO. 715 * Upon receiving a packet directed to a multicast address for which 716 it has at least one registration, the 6LR delivers a copy of the 717 packet as a unicast layer-2 frame to the LLA of each of the nodes 718 that registered to that multicast address. 720 * Upon receiving a packet directed to a multicast address for which 721 it has at least one registration, the 6LR delivers a copy of the 722 packet as a unicast layer-2 frame to the LLA of exactly one of the 723 nodes that registered to that multicast address. 725 8. Deployment considerations 727 With this specification, a RPL DODAG forms a realm, and multiple RPL 728 DODAGs may federated in a single RPL Instance administratively. This 729 means that a multicast address that needs to span a RPL DODAG MUST 730 use a scope of Realm-Local whereas a multicast address that needs to 731 span a RPL Instance MUST use a scope of Admin-Local as discussed in 732 section 3 of "IPv6 Multicast Address Scopes" [RFC7346]. 734 "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed 735 IPv4 addresses in IPv6 addresses. The Root of a DODAG may leverage 736 that technique to translate IPv4 traffic in IPv6 and route along the 737 RPL domain. When encapsulating an packet with an IPv4 multicast 738 Destination Address, it MUST use form a multicast address and use the 739 appropriate scope, Realm-Local or Admin-Local. 741 "Unicast-Prefix-based IPv6 Multicast Addresses" [RFC3306] enables to 742 form 2^32 multicast addresses from a single /64 prefix. If an IPv6 743 prefix is associated to an Instance or a RPL DODAG, this provides a 744 namespace that can be used in any desired fashion. It is for 745 instance possible for a standard defining organization to form its 746 own registry and allocate 32-bit values from that namespace to 747 network functions or device types. When used within a RPL deployment 748 that is associated with a /64 prefix the IPv6 multicast addresses can 749 be automatically derived from the prefix and the 32-bit value for 750 either a Realm-Local or an Admin-Local multicast address as needed in 751 the configuration. 753 IN a "green field" deployment where all nodes support this 754 specification, it is possible to deploy a single RPL Instance using a 755 multicast MOP for unicast, multicast and anycast addresses. 757 In a "brown field" where legacy devices that do not support this 758 specification co-exist with upgraded devices, it is RECOMMENDED to 759 deploy one RPL Instance in any Mode of Operation (typically MOP 1) 760 for unicast that legacy nodes can join, and a separate RPL Instance 761 dedicated to multicast and anycast operations using a multicast MOP. 763 To deploy a Storing Mode multicast operation using MOP 3 in a RPL 764 domain, it is required that there is enough density of RPL routers 765 that support MOP 3 to build a DODAG that covers all the potential 766 listeners and include the spanning multicast trees that are needed to 767 distribute the multicast flows. This might not be the case when 768 extending the capabilities of an existing network. 770 In the case of the new Non-Storing multicast MOP, arguably the new 771 support is only needed at the 6LRs that will accept multicast 772 listeners. It is still required that each listener can reach at 773 least one such 6LR, so the upgraded 6LRs must be deployed to cover 774 all the 6LN that need multicast services. 776 Using separate RPL Instances for in the one hand unicast traffic and 777 in the other hand anycast and multicast traffic allows to use 778 different objective function, one favoring the link quality up for 779 unicast collection and one favoring downwards link quality for 780 multicast distribution. 782 But this might be impractical in some use cases where the signaling 783 and the state to be installed in the devices are very constrained, 784 the upgraded devices are too sparse, or the devices do not support 785 more multiple instances. 787 When using a single RPL Instance, MOP 3 expects the Storing Mode of 788 Operation for both unicast and multicast, which is an issue in 789 constrained networks that typically use MOP 1 for unicast. This 790 specification allows a mixed mode that is signaled as MOP 1 in the 791 DIO messages for backward compatibility, where limited multicast and/ 792 or anycast is available, under the following conditions: 794 * There MUST be enough density of 6LRs that support the mixed mode 795 to cover the all the 6LNs that require multicast or anycast 796 services. In Storing Mode, there MUST be enough density or 6LR 797 that support the mixed mode to also form a DODAG to the Root. 799 * The RPL routers that support the mixed mode and are configured to 800 operate in in accordance with the desired operation in the 801 network. 803 * The MOP signaled in the RPL DODAG Information Object (DIO) 804 messages is MOP 1 to enable the legacy nodes to operate as leaves. 806 * The support of multicast and/or anycast in the RPL Instance SHOULD 807 be signaled by the 6LRs to the 6LN using a 6CIO, see Section 4. 809 * Alternatively, the support of multicast in the RPL domain can be 810 globally known by other means such as configuration or external 811 information such as support of a version of an industry standard 812 that mandates it. In that case, all the routers MUST support the 813 mixed mode. 815 9. Security Considerations 817 This specification extends [RFC8505], and the security section of 818 that document also applies to this document. In particular, the link 819 layer SHOULD be sufficiently protected to prevent rogue access. 821 10. Backward Compatibility 823 A legacy 6LN will not register multicast addresses and the service 824 will be the same when the network is upgraded. A legacy 6LR will not 825 set the M flag in the 6CIO and an upgraded 6LN will not register 826 multicast addresses. 828 Upon an EDAR message, a legacy 6LBR may not realize that the address 829 being registered is anycast or multicast, and return that it is 830 duplicate in the EDAC status. The 6LR MUST ignore a duplicate status 831 in the EDAR for anycast and multicast addresses. 833 As detailed in Section 8, it is possible to add multicast on an 834 existing MOP 1 deployment. 836 The combination of a multicast address and the M flag set to 0 in an 837 RTO in a MOP 3 RPL Instance is understood by the receiver that 838 supports this specification (the parent) as an indication that the 839 sender (child) does not support this specification, but the RTO is 840 accepted and processed as if the M flag was set for backward 841 compatibility. 843 When the DODAG is operated in MOP 3, a legacy node will not set the M 844 flag and still expect multicast service as specified in section 12 of 845 [RFC6550]. In MOP 3 an RTO that is received with a target that is 846 multicast and the M bit set to 0 MUST be considered as multicast and 847 MUST be processed as if the M flag is set. 849 11. IANA Considerations 851 Note to RFC Editor, to be removed: please replace "This RFC" 852 throughout this document by the RFC number for this specification 853 once it is allocated. Also, the I Field is defined in [RFC9010] but 854 is missing from the subregistry, so the bit positions must be added 855 for completeness. 857 IANA is requested to make changes under the "Internet Control Message 858 Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing 859 Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] 860 registries, as follows: 862 11.1. New EDAR Message Flags Subregistry 864 IANA is requested to create a new "EDAR Message Flags" subregistry of 865 the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" 866 registry as indicated in Table 1: 868 +---------------+---------------------------------------+-----------+ 869 | Bit Number | Meaning | Reference | 870 +---------------+---------------------------------------+-----------+ 871 | 0 (suggested) | A flag: Registered | This RFC | 872 | | Address is Anycast | | 873 +---------------+---------------------------------------+-----------+ 874 | 1 (suggested) | M flag: Registered | This RFC | 875 | | Address is Multicast | | 876 +---------------+---------------------------------------+-----------+ 878 Table 1: EDAR Message flags 880 11.2. New EARO flags 882 IANA is requested to make additions to the "Address Registration 883 Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message 884 Protocol version 6 (ICMPv6) Parameters" registry as indicated in 885 Table 2: 887 +---------------+-----------------------+-----------+ 888 | ARO flag | Meaning | Reference | 889 +---------------+-----------------------+-----------+ 890 | 2 (suggested) | A flag: Registration | This RFC | 891 | | for Anycast Address | | 892 +---------------+-----------------------+-----------+ 893 | 3 (suggested) | M flag: Registration | This RFC | 894 | | for Multicast Address | | 895 +---------------+-----------------------+-----------+ 896 | 4 and 5 | "I" Field | RFC 8505 | 897 +---------------+-----------------------+-----------+ 899 Table 2: New ARO flags 901 11.3. New RTO flags 903 IANA is requested to make additions to the "RPL Target Option Flags" 904 [IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power 905 and Lossy Networks (RPL)" registry as indicated in Table 3: 907 +---------------+---------------------------------------+-----------+ 908 | Bit Number | Meaning | Reference | 909 +---------------+---------------------------------------+-----------+ 910 | 2 (suggested) | A flag: Registered | This RFC | 911 | | Address is Anycast | | 912 +---------------+---------------------------------------+-----------+ 913 | 3 (suggested) | M flag: Registered | This RFC | 914 | | Address is Multicast | | 915 +---------------+---------------------------------------+-----------+ 917 Table 3: New RTO flags 919 11.4. New RPL Mode of Operation 921 IANA is requested to make an addition to the "Mode of Operation" 922 [IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and 923 Lossy Networks (RPL)" registry as indicated in Table 4: 925 +---------------+-------------------------------+-----------+ 926 | Value | Description | Reference | 927 +---------------+-------------------------------+-----------+ 928 | 5 (suggested) | Non-Storing Mode of Operation | This RFC | 929 | | with multicast support | | 930 +---------------+-------------------------------+-----------+ 932 Table 4: New RPL Mode of Operation 934 11.5. New 6LoWPAN Capability Bits 936 IANA is requested to make an addition to the "6LoWPAN Capability 937 Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet 938 Control Message Protocol version 6 (ICMPv6) Parameters" registry as 939 indicated in Table 5: 941 +----------------+------------------------------------+-----------+ 942 | Capability Bit | Meaning | Reference | 943 +----------------+------------------------------------+-----------+ 944 | 8 (suggested) | M flag: Registration for Multicast | This RFC | 945 | | and Anycast Addresses Supported | | 946 +----------------+------------------------------------+-----------+ 948 Table 5: New 6LoWPAN Capability Bits 950 12. Acknowledgments 952 13. Normative References 954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 955 Requirement Levels", BCP 14, RFC 2119, 956 DOI 10.17487/RFC2119, March 1997, 957 . 959 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 960 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 961 August 2002, . 963 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 964 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 965 2006, . 967 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 968 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 969 DOI 10.17487/RFC4861, September 2007, 970 . 972 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 973 Address Autoconfiguration", RFC 4862, 974 DOI 10.17487/RFC4862, September 2007, 975 . 977 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 978 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 979 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 980 Low-Power and Lossy Networks", RFC 6550, 981 DOI 10.17487/RFC6550, March 2012, 982 . 984 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 985 Bormann, "Neighbor Discovery Optimization for IPv6 over 986 Low-Power Wireless Personal Area Networks (6LoWPANs)", 987 RFC 6775, DOI 10.17487/RFC6775, November 2012, 988 . 990 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 991 DOI 10.17487/RFC7346, August 2014, 992 . 994 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 995 IPv6 over Low-Power Wireless Personal Area Networks 996 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 997 2014, . 999 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1000 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1001 May 2017, . 1003 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1004 (IPv6) Specification", STD 86, RFC 8200, 1005 DOI 10.17487/RFC8200, July 2017, 1006 . 1008 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1009 Perkins, "Registration Extensions for IPv6 over Low-Power 1010 Wireless Personal Area Network (6LoWPAN) Neighbor 1011 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1012 . 1014 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1015 (Routing Protocol for Low-Power and Lossy Networks) 1016 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1017 . 1019 [IANA.ICMP] 1020 IANA, "IANA Registry for ICMPv6", IANA, 1021 https://www.iana.org/assignments/icmpv6-parameters/ 1022 icmpv6-parameters.xhtml. 1024 [IANA.ICMP.ARO.FLG] 1025 IANA, "IANA Sub-Registry for the ARO Flags", IANA, 1026 https://www.iana.org/assignments/icmpv6-parameters/ 1027 icmpv6-parameters.xhtml#icmpv6-adress-registration-option- 1028 flags. 1030 [IANA.ICMP.6CIO] 1031 IANA, "IANA Sub-Registry for the 6LoWPAN Capability Bits", 1032 IANA, https://www.iana.org/assignments/icmpv6-parameters/ 1033 icmpv6-parameters.xhtml#sixlowpan-capability-bits. 1035 [IANA.RPL] IANA, "IANA Registry for the RPL", 1036 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml. 1038 [IANA.RPL.RTO.FLG] 1039 IANA, "IANA Sub-Registry for the RTO Flags", IANA, 1040 https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target- 1041 option-flags. 1043 [IANA.RPL.MOP] 1044 IANA, "IANA Sub-Registry for the RPL Mode of Operation", 1045 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml#mop. 1047 14. Informative References 1049 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1050 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1051 DOI 10.17487/RFC3810, June 2004, 1052 . 1054 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1055 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1056 Overview, Assumptions, Problem Statement, and Goals", 1057 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1058 . 1060 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1061 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1062 DOI 10.17487/RFC6282, September 2011, 1063 . 1065 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1066 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1067 February 2016, . 1069 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1070 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1071 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1072 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1073 2016, . 1075 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1076 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1077 DOI 10.17487/RFC6052, October 2010, 1078 . 1080 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 1081 Option Type, Routing Header for Source Routes, and IPv6- 1082 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1083 DOI 10.17487/RFC9008, April 2021, 1084 . 1086 [Wi-SUN] Heile, B., (Remy), B. L., Zhang, M., and C. E. Perkins, 1087 "Wi-SUN FAN Overview", Work in Progress, Internet-Draft, 1088 draft-heile-lpwan-wisun-overview-00, 3 July 2017, 1089 . 1092 [IEEE Std 802.15.4] 1093 IEEE standard for Information Technology, "IEEE Std 1094 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1095 and Physical Layer (PHY) Specifications for Low-Rate 1096 Wireless Personal Area Networks". 1098 [IEEE Std 802.11] 1099 IEEE standard for Information Technology, "IEEE Standard 1100 802.11 - IEEE Standard for Information Technology - 1101 Telecommunications and information exchange between 1102 systems Local and metropolitan area networks - Specific 1103 requirements - Part 11: Wireless LAN Medium Access Control 1104 (MAC) and Physical Layer (PHY) Specifications.", 1105 . 1107 [IEEE Std 802.15.1] 1108 IEEE standard for Information Technology, "IEEE Standard 1109 for Information Technology - Telecommunications and 1110 Information Exchange Between Systems - Local and 1111 Metropolitan Area Networks - Specific Requirements. - Part 1112 15.1: Wireless Medium Access Control (MAC) and Physical 1113 Layer (PHY) Specifications for Wireless Personal Area 1114 Networks (WPANs)". 1116 Author's Address 1118 Pascal Thubert (editor) 1119 Cisco Systems, Inc 1120 Building D 1121 45 Allee des Ormes - BP1200 1122 06254 Mougins - Sophia Antipolis 1123 France 1125 Phone: +33 497 23 26 34 1126 Email: pthubert@cisco.com