idnits 2.17.1 draft-ietf-6lo-multicast-registration-03.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 (13 December 2021) is 864 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) 13 December 2021 5 Intended status: Standards Track 6 Expires: 16 June 2022 8 IPv6 Neighbor Discovery Multicast Address Listener Registration 9 draft-ietf-6lo-multicast-registration-03 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 16 June 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 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 . . . . . . . . . . . . . . . . . . . . . 16 71 9. Deployment considerations . . . . . . . . . . . . . . . . . . 17 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19 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 and it MUST set the M flag in the EARO for those 666 addresses. 668 * The 6LN MAY set the R flag in the EARO to obtain the delivery of 669 the multicast packets by the 6LR, e.g., by MLD proxy operations, 670 or by injecting the address in a route-over subnet or in the 671 Protocol Independent Multicast [RFC7761] protocol. 673 * The 6LN MUST also register all the IPv6 anycast addresses that it 674 supports and it MUST set the A flag in the EARO for those 675 addresses. 677 * The 6LR and the 6LBR are extended to accept more than one 678 registration for the same address when it is anycast or multicast, 679 since multiple 6LNs may subscribe to the same address of these 680 types. In both cases, the Registration Ownership Verifier (ROVR) 681 in the EARO identifies uniquely a registration within the 682 namespace of the Registered Address. 684 * The 6LR MUST maintain a registration state per tuple (IPv6 685 address, ROVR) for both anycast and multicast types of address. 686 It SHOULD notify the 6LBR with an EDAR message, unless it 687 determined that the 6LBR is legacy and does not support this 688 specification. In turn, the 6LBR MUST maintain a registration 689 state per tuple (IPv6 address, ROVR) for both anycast and 690 multicast types of address. 692 7. Updating RFC 9010 694 With [RFC9010]: 696 * The 6LR injects only unicast routes in RPL 698 * Upon a registration with the R flag set to 1 in the EARO, the 6LR 699 injects the address in the RPL unicast support. 701 * Upon receiving a packet directed to a unicast address for which it 702 has an active registration, the 6LR delivers the packet as a 703 unicast layer-2 frame to the LLA the nodes that registered the 704 unicast address. 706 This specification adds the following behavior: 708 * Upon a registration with the R and the M flags set to 1 in the 709 EARO, the 6LR injects the address in the RPL multicast support and 710 sets the M flag in the RTO. 712 * Upon a registration with the R and the A flags set to 1 in the 713 EARO, the 6LR injects the address in the new RPL anycast support 714 and sets the A flag in the RTO. 716 * Upon receiving a packet directed to a multicast address for which 717 it has at least one registration, the 6LR delivers a copy of the 718 packet as a unicast layer-2 frame to the LLA of each of the nodes 719 that registered to that multicast address. 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 exactly one of the 724 nodes that registered to that multicast address. 726 8. Leveraging RFC 8929 728 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks 729 [RFC8928] was defined to protect the ownership of unicast IPv6 730 addresses that are registered with [RFC8505]. 732 With [RFC8928], it is possible for a node to autoconfigure a pair of 733 public and private keys and use them to sign the registration of 734 addresses that are either autoconfigured or obtained through other 735 methods. 737 The first hop router (the 6LR) may then validate a registration and 738 perform source address validation on packets coming from the sender 739 node (the 6LN). 741 Anycast and multicast addresses are not owned by one node. Multiple 742 nodes may subscribe to the same address. Also, anycast and multicast 743 addresses are not used to source traffic. In that context, the 744 method specified in [RFC8928] cannot be used with autoconfigured 745 keypairs to protect a single ownership. 747 For an anycast or a multicast address, it is still possible to 748 leverage [RFC8928] to enforce the right to subscribe. A keypair MUST 749 be associated with the address before it is deployed, and a ROVR MUST 750 be generated from that keypair as specified in [RFC8928]. The 751 address and the ROVR MUST then be installed in the 6LBR so it can 752 recognize the address and compare the ROVR on the first registration. 754 The keypair MUST then be provisioned in each node that needs to 755 subscribe to the anycast or multicast address, so the node can follow 756 the steps in [RFC8928] to register the address. 758 9. Deployment considerations 760 With this specification, a RPL DODAG forms a realm, and multiple RPL 761 DODAGs may federated in a single RPL Instance administratively. This 762 means that a multicast address that needs to span a RPL DODAG MUST 763 use a scope of Realm-Local whereas a multicast address that needs to 764 span a RPL Instance MUST use a scope of Admin-Local as discussed in 765 section 3 of "IPv6 Multicast Address Scopes" [RFC7346]. 767 "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed 768 IPv4 addresses in IPv6 addresses. The Root of a DODAG may leverage 769 that technique to translate IPv4 traffic in IPv6 and route along the 770 RPL domain. When encapsulating an packet with an IPv4 multicast 771 Destination Address, it MUST use form a multicast address and use the 772 appropriate scope, Realm-Local or Admin-Local. 774 "Unicast-Prefix-based IPv6 Multicast Addresses" [RFC3306] enables to 775 form 2^32 multicast addresses from a single /64 prefix. If an IPv6 776 prefix is associated to an Instance or a RPL DODAG, this provides a 777 namespace that can be used in any desired fashion. It is for 778 instance possible for a standard defining organization to form its 779 own registry and allocate 32-bit values from that namespace to 780 network functions or device types. When used within a RPL deployment 781 that is associated with a /64 prefix the IPv6 multicast addresses can 782 be automatically derived from the prefix and the 32-bit value for 783 either a Realm-Local or an Admin-Local multicast address as needed in 784 the configuration. 786 IN a "green field" deployment where all nodes support this 787 specification, it is possible to deploy a single RPL Instance using a 788 multicast MOP for unicast, multicast and anycast addresses. 790 In a "brown field" where legacy devices that do not support this 791 specification co-exist with upgraded devices, it is RECOMMENDED to 792 deploy one RPL Instance in any Mode of Operation (typically MOP 1) 793 for unicast that legacy nodes can join, and a separate RPL Instance 794 dedicated to multicast and anycast operations using a multicast MOP. 796 To deploy a Storing Mode multicast operation using MOP 3 in a RPL 797 domain, it is required that there is enough density of RPL routers 798 that support MOP 3 to build a DODAG that covers all the potential 799 listeners and include the spanning multicast trees that are needed to 800 distribute the multicast flows. This might not be the case when 801 extending the capabilities of an existing network. 803 In the case of the new Non-Storing multicast MOP, arguably the new 804 support is only needed at the 6LRs that will accept multicast 805 listeners. It is still required that each listener can reach at 806 least one such 6LR, so the upgraded 6LRs must be deployed to cover 807 all the 6LN that need multicast services. 809 Using separate RPL Instances for in the one hand unicast traffic and 810 in the other hand anycast and multicast traffic allows to use 811 different objective function, one favoring the link quality up for 812 unicast collection and one favoring downwards link quality for 813 multicast distribution. 815 But this might be impractical in some use cases where the signaling 816 and the state to be installed in the devices are very constrained, 817 the upgraded devices are too sparse, or the devices do not support 818 more multiple instances. 820 When using a single RPL Instance, MOP 3 expects the Storing Mode of 821 Operation for both unicast and multicast, which is an issue in 822 constrained networks that typically use MOP 1 for unicast. This 823 specification allows a mixed mode that is signaled as MOP 1 in the 824 DIO messages for backward compatibility, where limited multicast and/ 825 or anycast is available, under the following conditions: 827 * There MUST be enough density of 6LRs that support the mixed mode 828 to cover the all the 6LNs that require multicast or anycast 829 services. In Storing Mode, there MUST be enough density or 6LR 830 that support the mixed mode to also form a DODAG to the Root. 832 * The RPL routers that support the mixed mode and are configured to 833 operate in in accordance with the desired operation in the 834 network. 836 * The MOP signaled in the RPL DODAG Information Object (DIO) 837 messages is MOP 1 to enable the legacy nodes to operate as leaves. 839 * The support of multicast and/or anycast in the RPL Instance SHOULD 840 be signaled by the 6LRs to the 6LN using a 6CIO, see Section 4. 842 * Alternatively, the support of multicast in the RPL domain can be 843 globally known by other means such as configuration or external 844 information such as support of a version of an industry standard 845 that mandates it. In that case, all the routers MUST support the 846 mixed mode. 848 10. Security Considerations 850 This specification extends [RFC8505], and the security section of 851 that document also applies to this document. In particular, the link 852 layer SHOULD be sufficiently protected to prevent rogue access. 854 Section 8 leverages [RFC8928] to prevent an unwanted subscriber to 855 register for an anycast of a multicast address. This mechanism comes 856 with a keypair that is shared between all subscribers. A shared key 857 is prone to be stolen and the level of protection can only go down 858 with time. 860 It is possible to update the keys associated to an address in all the 861 6LNs, but the flow is not clearly documented and may not complete in 862 due time for all nodes in LLN use cases. It may be simpler to 863 install a all-new address with new keys over a period of time, and 864 switch the traffic to that address when the migreaiton is complete. 866 11. Backward Compatibility 868 A legacy 6LN will not register multicast addresses and the service 869 will be the same when the network is upgraded. A legacy 6LR will not 870 set the M flag in the 6CIO and an upgraded 6LN will not register 871 multicast addresses. 873 Upon an EDAR message, a legacy 6LBR may not realize that the address 874 being registered is anycast or multicast, and return that it is 875 duplicate in the EDAC status. The 6LR MUST ignore a duplicate status 876 in the EDAR for anycast and multicast addresses. 878 As detailed in Section 9, it is possible to add multicast on an 879 existing MOP 1 deployment. 881 The combination of a multicast address and the M flag set to 0 in an 882 RTO in a MOP 3 RPL Instance is understood by the receiver that 883 supports this specification (the parent) as an indication that the 884 sender (child) does not support this specification, but the RTO is 885 accepted and processed as if the M flag was set for backward 886 compatibility. 888 When the DODAG is operated in MOP 3, a legacy node will not set the M 889 flag and still expect multicast service as specified in section 12 of 890 [RFC6550]. In MOP 3 an RTO that is received with a target that is 891 multicast and the M bit set to 0 MUST be considered as multicast and 892 MUST be processed as if the M flag is set. 894 12. IANA Considerations 896 Note to RFC Editor, to be removed: please replace "This RFC" 897 throughout this document by the RFC number for this specification 898 once it is allocated. Also, the I Field is defined in [RFC9010] but 899 is missing from the subregistry, so the bit positions must be added 900 for completeness. 902 IANA is requested to make changes under the "Internet Control Message 903 Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing 904 Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] 905 registries, as follows: 907 12.1. New EDAR Message Flags Subregistry 909 IANA is requested to create a new "EDAR Message Flags" subregistry of 910 the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" 911 registry as indicated in Table 1: 913 +---------------+---------------------------------------+-----------+ 914 | Bit Number | Meaning | Reference | 915 +---------------+---------------------------------------+-----------+ 916 | 0 (suggested) | A flag: Registered | This RFC | 917 | | Address is Anycast | | 918 +---------------+---------------------------------------+-----------+ 919 | 1 (suggested) | M flag: Registered | This RFC | 920 | | Address is Multicast | | 921 +---------------+---------------------------------------+-----------+ 923 Table 1: EDAR Message flags 925 12.2. New EARO flags 927 IANA is requested to make additions to the "Address Registration 928 Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message 929 Protocol version 6 (ICMPv6) Parameters" registry as indicated in 930 Table 2: 932 +---------------+-----------------------+-----------+ 933 | ARO flag | Meaning | Reference | 934 +---------------+-----------------------+-----------+ 935 | 2 (suggested) | A flag: Registration | This RFC | 936 | | for Anycast Address | | 937 +---------------+-----------------------+-----------+ 938 | 3 (suggested) | M flag: Registration | This RFC | 939 | | for Multicast Address | | 940 +---------------+-----------------------+-----------+ 941 | 4 and 5 | "I" Field | RFC 8505 | 942 +---------------+-----------------------+-----------+ 944 Table 2: New ARO flags 946 12.3. New RTO flags 948 IANA is requested to make additions to the "RPL Target Option Flags" 949 [IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power 950 and Lossy Networks (RPL)" registry as indicated in Table 3: 952 +---------------+---------------------------------------+-----------+ 953 | Bit Number | Meaning | Reference | 954 +---------------+---------------------------------------+-----------+ 955 | 2 (suggested) | A flag: Registered | This RFC | 956 | | Address is Anycast | | 957 +---------------+---------------------------------------+-----------+ 958 | 3 (suggested) | M flag: Registered | This RFC | 959 | | Address is Multicast | | 960 +---------------+---------------------------------------+-----------+ 962 Table 3: New RTO flags 964 12.4. New RPL Mode of Operation 966 IANA is requested to make an addition to the "Mode of Operation" 967 [IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and 968 Lossy Networks (RPL)" registry as indicated in Table 4: 970 +---------------+-------------------------------+-----------+ 971 | Value | Description | Reference | 972 +---------------+-------------------------------+-----------+ 973 | 5 (suggested) | Non-Storing Mode of Operation | This RFC | 974 | | with multicast support | | 975 +---------------+-------------------------------+-----------+ 977 Table 4: New RPL Mode of Operation 979 12.5. New 6LoWPAN Capability Bits 981 IANA is requested to make an addition to the "6LoWPAN Capability 982 Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet 983 Control Message Protocol version 6 (ICMPv6) Parameters" registry as 984 indicated in Table 5: 986 +----------------+------------------------------------+-----------+ 987 | Capability Bit | Meaning | Reference | 988 +----------------+------------------------------------+-----------+ 989 | 8 (suggested) | M flag: Registration for Multicast | This RFC | 990 | | and Anycast Addresses Supported | | 991 +----------------+------------------------------------+-----------+ 993 Table 5: New 6LoWPAN Capability Bits 995 13. Acknowledgments 997 14. Normative References 999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1000 Requirement Levels", BCP 14, RFC 2119, 1001 DOI 10.17487/RFC2119, March 1997, 1002 . 1004 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1005 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1006 August 2002, . 1008 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1009 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1010 2006, . 1012 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1013 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1014 DOI 10.17487/RFC4861, September 2007, 1015 . 1017 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1018 Address Autoconfiguration", RFC 4862, 1019 DOI 10.17487/RFC4862, September 2007, 1020 . 1022 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1023 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1024 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1025 Low-Power and Lossy Networks", RFC 6550, 1026 DOI 10.17487/RFC6550, March 2012, 1027 . 1029 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1030 Bormann, "Neighbor Discovery Optimization for IPv6 over 1031 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1032 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1033 . 1035 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1036 DOI 10.17487/RFC7346, August 2014, 1037 . 1039 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1040 IPv6 over Low-Power Wireless Personal Area Networks 1041 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1042 2014, . 1044 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1045 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1046 May 2017, . 1048 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1049 (IPv6) Specification", STD 86, RFC 8200, 1050 DOI 10.17487/RFC8200, July 2017, 1051 . 1053 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1054 Perkins, "Registration Extensions for IPv6 over Low-Power 1055 Wireless Personal Area Network (6LoWPAN) Neighbor 1056 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1057 . 1059 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 1060 "Address-Protected Neighbor Discovery for Low-Power and 1061 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 1062 2020, . 1064 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1065 (Routing Protocol for Low-Power and Lossy Networks) 1066 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1067 . 1069 [IANA.ICMP] 1070 IANA, "IANA Registry for ICMPv6", IANA, 1071 https://www.iana.org/assignments/icmpv6-parameters/ 1072 icmpv6-parameters.xhtml. 1074 [IANA.ICMP.ARO.FLG] 1075 IANA, "IANA Sub-Registry for the ARO Flags", IANA, 1076 https://www.iana.org/assignments/icmpv6-parameters/ 1077 icmpv6-parameters.xhtml#icmpv6-adress-registration-option- 1078 flags. 1080 [IANA.ICMP.6CIO] 1081 IANA, "IANA Sub-Registry for the 6LoWPAN Capability Bits", 1082 IANA, https://www.iana.org/assignments/icmpv6-parameters/ 1083 icmpv6-parameters.xhtml#sixlowpan-capability-bits. 1085 [IANA.RPL] IANA, "IANA Registry for the RPL", 1086 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml. 1088 [IANA.RPL.RTO.FLG] 1089 IANA, "IANA Sub-Registry for the RTO Flags", IANA, 1090 https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target- 1091 option-flags. 1093 [IANA.RPL.MOP] 1094 IANA, "IANA Sub-Registry for the RPL Mode of Operation", 1095 IANA, https://www.iana.org/assignments/rpl/rpl.xhtml#mop. 1097 15. Informative References 1099 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1100 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1101 DOI 10.17487/RFC3810, June 2004, 1102 . 1104 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1105 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1106 Overview, Assumptions, Problem Statement, and Goals", 1107 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1108 . 1110 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1111 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1112 DOI 10.17487/RFC6282, September 2011, 1113 . 1115 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1116 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1117 February 2016, . 1119 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1120 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1121 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1122 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1123 2016, . 1125 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1126 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1127 DOI 10.17487/RFC6052, October 2010, 1128 . 1130 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 1131 Option Type, Routing Header for Source Routes, and IPv6- 1132 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1133 DOI 10.17487/RFC9008, April 2021, 1134 . 1136 [Wi-SUN] Heile, B., (Remy), B. L., Zhang, M., and C. E. Perkins, 1137 "Wi-SUN FAN Overview", Work in Progress, Internet-Draft, 1138 draft-heile-lpwan-wisun-overview-00, 3 July 2017, 1139 . 1142 [IEEE Std 802.15.4] 1143 IEEE standard for Information Technology, "IEEE Std 1144 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1145 and Physical Layer (PHY) Specifications for Low-Rate 1146 Wireless Personal Area Networks". 1148 [IEEE Std 802.11] 1149 IEEE standard for Information Technology, "IEEE Standard 1150 802.11 - IEEE Standard for Information Technology - 1151 Telecommunications and information exchange between 1152 systems Local and metropolitan area networks - Specific 1153 requirements - Part 11: Wireless LAN Medium Access Control 1154 (MAC) and Physical Layer (PHY) Specifications.", 1155 . 1157 [IEEE Std 802.15.1] 1158 IEEE standard for Information Technology, "IEEE Standard 1159 for Information Technology - Telecommunications and 1160 Information Exchange Between Systems - Local and 1161 Metropolitan Area Networks - Specific Requirements. - Part 1162 15.1: Wireless Medium Access Control (MAC) and Physical 1163 Layer (PHY) Specifications for Wireless Personal Area 1164 Networks (WPANs)". 1166 Author's Address 1168 Pascal Thubert (editor) 1169 Cisco Systems, Inc 1170 Building D 1171 45 Allee des Ormes - BP1200 1172 06254 Mougins - Sophia Antipolis 1173 France 1175 Phone: +33 497 23 26 34 1176 Email: pthubert@cisco.com